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-5838] Can't infer type of inout parameter for an operator #48408

Open
swift-ci opened this issue Sep 5, 2017 · 8 comments
Open

[SR-5838] Can't infer type of inout parameter for an operator #48408

swift-ci opened this issue Sep 5, 2017 · 8 comments
Assignees
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

@swift-ci
Copy link
Collaborator

swift-ci commented Sep 5, 2017

Previous ID SR-5838
Radar None
Original Reporter hlovatt (JIRA User)
Type Bug

Attachment: Download

Environment

MacOS 10.12.6

Xcode 9 beta 6

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

md5: e1f37be7e1af0d30689c36d19ce7d871

relates to:

  • SR-1420 Provide compiler warning when shadowing generic type

Issue Description:

See attached playground.

The compiler can't infer the type of the argument to the operator.

Seems to only be a problem with inout parameters and operators.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Sep 5, 2017

Comment by Howard Lovatt (JIRA)

Looks like it could be a general problem with operators and generic type inference. Attached another example that gives a different error and doesn't use inout parameters.

!st playground using inout is Operator..., 2nd without inout is Reference...

@belkadan
Copy link
Contributor

belkadan commented Sep 5, 2017

The error messages need work, but the problem is that you shouldn't be making the function generic, because the context is already generic. You've shadowed the enclosing T with a new one.

@belkadan
Copy link
Contributor

belkadan commented Sep 5, 2017

cc @xedin

@swift-ci
Copy link
Collaborator Author

swift-ci commented Sep 6, 2017

Comment by Howard Lovatt (JIRA)

Thanks Jordan, that is definitely part of the problem. Deleting the extra T cures the 2nd example but the 1st example still fails. IE:

class Box<T> {

var value: T

init(\_ value: T) { self.value = value }

/// Unboxing operator.

static func \>\> (left: Box\<T\>, right: inout T?) {

    right = left.value

}

}

let b = Box("Test")

var u: String?

b >> &u // ERROR: Cannot convert value of type 'Box<String>' to expected argument type 'Box<_>'

u

Still fails with the same error message.

@belkadan
Copy link
Contributor

belkadan commented Sep 6, 2017

Ah, interesting. Moreover,

b >> u

actually works. I think this is fallout from our support for assignment operators where the & is implied.

@belkadan
Copy link
Contributor

belkadan commented Sep 6, 2017

To be clear, I would say assignment operators should only imply & on the first argument, and non-assignment operators like >> shouldn't imply it on either.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Sep 7, 2017

Comment by Howard Lovatt (JIRA)

Thanks Jordan. I can use the workaround until fixed - actually in my use case it is better than having to put the & in since I am using the operator for assignment.

As extra information - if I change to my actual operator - I used >> for simplicity in example - then the error message changes to "ambiguous expression type":

infix operator ~~> : MultiplicationPrecedence

class Box<T> {

var value: T

init(\_ value: T) { self.value = value }

/// Unboxing operator.

static func \~\~\> (left: Box\<T\>, right: inout T?) {

    right = left.value

}

}

let b = Box("Test")

var u: String?

b ~~> &u // error: expression type '()' is ambiguous without more context

u

Thanks for the help.

@xedin
Copy link
Member

xedin commented Sep 27, 2017

hlovatt (JIRA User) The problem here is that an argument of the inout parameter has to be @lvalue which `u` already is, but if you add `&` before it, it make it an `inout` and there is a argument to parameter mismatch in the operator call because it would try to apply `inout` argument to `inout` parameter` which is incorrect. Diagnostic is very misleading though, so I'm going to try to improve it.

@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