Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-7921] Inconsistent ability to append sequences of non-optional E to those of optional E? #50456

Open
Lukasa opened this issue Jun 7, 2018 · 3 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself standard library Area: Standard library umbrella type checker Area → compiler: Semantic analysis

Comments

@Lukasa
Copy link
Contributor

Lukasa commented Jun 7, 2018

Previous ID SR-7921
Radar rdar://problem/40970972
Original Reporter @Lukasa
Type Bug
Environment

Swift 4.2 snapshot

Additional Detail from JIRA
Votes 1
Component/s Compiler, Standard Library
Labels Bug, TypeChecker
Assignee None
Priority Medium

md5: 452b965635b75a8ef058d4b29a3d8c0f

Issue Description:

The following code fails to compile:

var y: ContiguousArray<Int?> = [1, 2, nil, 4, 5, nil]
var z: ContiguousArray<Int> = [7, 8, 9, 10, 11, 12]

y.append(contentsOf: z)

with the error:

test.swift:4:9: error: extraneous argument label 'contentsOf:' in call
y.append(contentsOf: z)
        ^~~~~~~~~~~~~

However, if I use regular Array this problem does not occur. This code compiles:

var y: ContiguousArray<Int?> = [1, 2, nil, 4, 5, nil]
var z = [7, 8, 9, 10, 11, 12]

y.append(contentsOf: z)

It seems that there is an escape hatch for appending the contents of Array<E> to Sequence<E?>, but not a more general one. That seems weirdly inconsistent.

@belkadan
Copy link
Contributor

belkadan commented Jun 8, 2018

I think the compiler knows how to handle covariance for Arrays, Sets, and Dictionaries, but nothing else. Maybe ContiguousArray should have been in that blessed set. @rudkx, @xedin?

@xedin
Copy link
Member

xedin commented Jun 9, 2018

@swift-ci create

@xedin
Copy link
Member

xedin commented Jun 9, 2018

It looks like this might be made to work in general case if the way requirements are generated in altered to support subtyping relationship. Right now when same-type requirements are added they create corresponding Equal constraint, instead it should be Conversion and their type direction has to be flipped.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself standard library Area: Standard library umbrella type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

3 participants