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-6908] Unable to infer heterogenous Array type when concatenating Arrays #49457

Open
NachoSoto opened this issue Feb 2, 2018 · 3 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself type checker Area → compiler: Semantic analysis

Comments

@NachoSoto
Copy link
Contributor

Previous ID SR-6908
Radar rdar://problem/37162672
Original Reporter @NachoSoto
Type Bug

Attachment: Download

Environment
  • Swift version 4.0.3 (swiftlang-900.0.74.1 clang-900.0.39.2)

  • Swift version 4.1 (swiftlang-902.0.34 clang-902.0.30)

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

md5: 81871d183f8c2fdb991c92349182ba21

Issue Description:

Consider this hierarchy:

class A {}
class B: A {}
class C: A {}

This works:

// Inferred as [A]
let a1 = [B(), B()] + [C()]

However, let's create an array of `C`s:

// Inferred as [C]
let cs = [C()]

I can create an Array of `A`s by explicitly declaring the type:

let a2: [A] = [B(), B()] + cs

However, without the explicit type, it's unable to infer it:

let a3 = [B(), B()] + cs

Producing one okay-diagnostic, and a diagnostic that makes no sense:

error: repl.swift:6:20: error: binary operator '+' cannot be applied to operands of type '[B]' and '[C]'
let a3 = [B(), B()] + cs
        ~~~~~~~~~~ ^ ~~

repl.swift:6:20: note: overloads for '+' exist with these partially matching parameter lists: (C, S), (S, C), (RRC1, RRC2)
let a3 = [B(), B()] + cs
                   ^

Note that the second diagnostic is not because of the similarity of the class names, I get the same in my project:

@jckarter
Copy link
Member

jckarter commented Feb 2, 2018

@swift-ci create

@rudkx
Copy link
Member

rudkx commented Feb 3, 2018

The reason this happens is that the + on RangeReplacableCollection takes two types and expects the element types to be equal.

The type checker is somewhat limited in inferring common super types, so we don't really attempt to infer [A] as a type when a typed operand (cs in this case) is provided.

The reason it works when you only provide collection literals is that we infer the individual collections to be typed as [A], so the same-type constraint check passes.

So I guess to summarize our support for collection upcasting is pretty limited at the moment.

@NachoSoto
Copy link
Contributor Author

Makes sense. To a user like me though (i.e., not Swift contributor), this seems like a big missing piece that I wouldn't expect to find at this day and age with Swift 4.1 :/

@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 type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

3 participants