Re: [swift-users] Overload Resolution of Binary Operators

[Toni Suter via swift-users]

@David
If you would split up the statement like this...

let x = 0 *** 4
let result = x +++ 0

... the compiler would report an ambiguity error, because both overloads of *** 
are valid and of equivalent priority.
You could do something like this though:

let x: Int = 0 *** 4// picks f2
let result = x +++ 0// picks f4

or this:

let x: String = 0 *** 4 // picks f1
let result = x +++ 0// picks f3

Now the compiler has enough type information to know which overload to pick.

@Mark
Ok, thanks. I reported a bug at https://bugs.swift.org/browse/SR-3209 
 and assigned it to you.

@Rien
Yes, it is even possible to use the operators as the example above shows, but 
it is requires a bit more explicit
type information so that the type checker knows which overload to pick.

Thanks and best regards,
Toni

> Am 15.11.2016 um 08:41 schrieb Rien :
> 
> I seem to remember that while it is possible to define, the compiler will 
> yield an error if you try to use the functions (“cannot resolve”).
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Swiftrien
> Project: http://swiftfire.nl
> 
> 
> 
> 
>> On 14 Nov 2016, at 23:05, Toni Suter via swift-users  
>> wrote:
>> 
>> Hi,
>> 
>> I would have expected that the following code reports an error, because
>> of ambiguous function overloads:
>> 
>> infix operator ***: MultiplicationPrecedence
>> infix operator +++: AdditionPrecedence
>> 
>> func ***(x: Int, y: Int) -> String {
>>  print("f1")
>>  return ""
>> }
>> 
>> func ***(x: Int, y: Int) -> Int {
>>  print("f2")
>>  return 0
>> }
>> 
>> func +++(x: String, y: Int) -> Int {
>>  print("f3")
>>  return 0
>> }
>> 
>> func +++(x: Int, y: Int) -> Int {
>>  print("f4")
>>  return 0
>> }
>> 
>> let result = 0 *** 4 +++ 0   // prints f2 and f4
>> 
>> 
>> As far as I can tell, there are two possible overload resolutions: f1 + f3 
>> or f2 + f4.
>> I thought that these two solutions get an "equivalent score" and therefore 
>> there would
>> be a compile error. However, that's not the case. Instead, the type checker 
>> picks
>> f2 and f4.
>> 
>> So, I guess my question is, whether there is some rule, that prefers
>> operators, which have the same argument types and the same return type
>> or whether this is simply a bug.
>> 
>> Thanks and best regards,
>> Toni
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Overload Resolution of Binary Operators

[Rien via swift-users]

I seem to remember that while it is possible to define, the compiler will yield 
an error if you try to use the functions (“cannot resolve”).

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 14 Nov 2016, at 23:05, Toni Suter via swift-users  
> wrote:
> 
> Hi,
> 
> I would have expected that the following code reports an error, because
> of ambiguous function overloads:
> 
> infix operator ***: MultiplicationPrecedence
> infix operator +++: AdditionPrecedence
> 
> func ***(x: Int, y: Int) -> String {
>   print("f1")
>   return ""
> }
> 
> func ***(x: Int, y: Int) -> Int {
>   print("f2")
>   return 0
> }
> 
> func +++(x: String, y: Int) -> Int {
>   print("f3")
>   return 0
> }
> 
> func +++(x: Int, y: Int) -> Int {
>   print("f4")
>   return 0
> }
> 
> let result = 0 *** 4 +++ 0// prints f2 and f4
> 
> 
> As far as I can tell, there are two possible overload resolutions: f1 + f3 or 
> f2 + f4.
> I thought that these two solutions get an "equivalent score" and therefore 
> there would
> be a compile error. However, that's not the case. Instead, the type checker 
> picks
> f2 and f4.
> 
> So, I guess my question is, whether there is some rule, that prefers
> operators, which have the same argument types and the same return type
> or whether this is simply a bug.
> 
> Thanks and best regards,
> Toni
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Overload Resolution of Binary Operators

[Mark Lacey via swift-users]

> On Nov 14, 2016, at 2:05 PM, Toni Suter via swift-users 
>  wrote:
> 
> Hi,
> 
> I would have expected that the following code reports an error, because
> of ambiguous function overloads:
> 
> infix operator ***: MultiplicationPrecedence
> infix operator +++: AdditionPrecedence
> 
> func ***(x: Int, y: Int) -> String {
>   print("f1")
>   return ""
> }
> 
> func ***(x: Int, y: Int) -> Int {
>   print("f2")
>   return 0
> }
> 
> func +++(x: String, y: Int) -> Int {
>   print("f3")
>   return 0
> }
> 
> func +++(x: Int, y: Int) -> Int {
>   print("f4")
>   return 0
> }
> 
> let result = 0 *** 4 +++ 0// prints f2 and f4
> 
> 
> As far as I can tell, there are two possible overload resolutions: f1 + f3 or 
> f2 + f4.
> I thought that these two solutions get an "equivalent score" and therefore 
> there would
> be a compile error. However, that's not the case. Instead, the type checker 
> picks
> f2 and f4.
> 
> So, I guess my question is, whether there is some rule, that prefers
> operators, which have the same argument types and the same return type
> or whether this is simply a bug.

It’s a bug, and one that I’m aware of, but I’m not aware of anything in JIRA 
for it. Do you mind opening an issue there and assigning it to me?

Mark

> 
> Thanks and best regards,
> Toni
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Overload Resolution of Binary Operators

[David Sweeris via swift-users]

> On Nov 14, 2016, at 16:05, Toni Suter via swift-users  
> wrote:
> 
> Hi,
> 
> I would have expected that the following code reports an error, because
> of ambiguous function overloads:
> 
> infix operator ***: MultiplicationPrecedence
> infix operator +++: AdditionPrecedence
> 
> func ***(x: Int, y: Int) -> String {
>   print("f1")
>   return ""
> }
> 
> func ***(x: Int, y: Int) -> Int {
>   print("f2")
>   return 0
> }
> 
> func +++(x: String, y: Int) -> Int {
>   print("f3")
>   return 0
> }
> 
> func +++(x: Int, y: Int) -> Int {
>   print("f4")
>   return 0
> }
> 
> let result = 0 *** 4 +++ 0// prints f2 and f4
> 
> 
> As far as I can tell, there are two possible overload resolutions: f1 + f3 or 
> f2 + f4.
> I thought that these two solutions get an "equivalent score" and therefore 
> there would
> be a compile error. However, that's not the case. Instead, the type checker 
> picks
> f2 and f4.
> 
> So, I guess my question is, whether there is some rule, that prefers
> operators, which have the same argument types and the same return type
> or whether this is simply a bug.

Odd... Perhaps the compiler is convinced the result of the *** operation needs 
to be an Int? Dunno why that would be, though.

What happens if you split it up into two statements?

- Dave Sweeris ___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Overload Resolution of Binary Operators

[Toni Suter via swift-users]

Hi,

I would have expected that the following code reports an error, because
of ambiguous function overloads:

infix operator ***: MultiplicationPrecedence
infix operator +++: AdditionPrecedence

func ***(x: Int, y: Int) -> String {
print("f1")
return ""
}

func ***(x: Int, y: Int) -> Int {
print("f2")
return 0
}

func +++(x: String, y: Int) -> Int {
print("f3")
return 0
}

func +++(x: Int, y: Int) -> Int {
print("f4")
return 0
}

let result = 0 *** 4 +++ 0  // prints f2 and f4


As far as I can tell, there are two possible overload resolutions: f1 + f3 or 
f2 + f4.
I thought that these two solutions get an "equivalent score" and therefore 
there would
be a compile error. However, that's not the case. Instead, the type checker 
picks
f2 and f4.

So, I guess my question is, whether there is some rule, that prefers
operators, which have the same argument types and the same return type
or whether this is simply a bug.

Thanks and best regards,
Toni___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Overload Resolution

[Toni Suter via swift-users]

Hi Mark,

Thanks for pointing me into the right direction!

Best regards,
Toni

> Am 06.10.2016 um 16:31 schrieb Mark Lacey :
> 
> 
>> On Oct 6, 2016, at 4:53 AM, Toni Suter via swift-users 
>> > wrote:
>> 
>> Hi,
>> 
>> Does someone know a good explanation / summary of Swift's overload 
>> resolution rules?
>> After reading 
>> https://github.com/apple/swift/blob/master/docs/TypeChecker.rst 
>>  I 
>> understand
>> that the overloading resolution happens as part of the constraint solving 
>> step in the type 
>> checker, but maybe there's a document somewhere, that explains the rules in 
>> more detail?
> 
> I don’t know of any existing documentation for overload resolution. I was 
> hoping to find some time to write something up in the next few months, but 
> I’m not sure exactly when I might get to it.
> 
> In the meantime the best advice I can give is to dig into the code a bit to 
> understand what’s going on. The type checker runs the constraint solver and 
> collections all applicable solutions, and then compares these solutions to 
> find a winner. That step is done in ConstraintSystem::findBestSolution() in 
> CSRanking.cpp. That calls into ConstraintSystem::compareSolutions(), which is 
> where most of the specific logic is. It checks overloads, and then checks the 
> specific type bindings in each solution.
> 
> That code is reasonably well documented, so even without knowing a lot about 
> the compiler internals I think it shouldn’t be too hard to follow.
> 
> Mark
> 
> 

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Overload Resolution

[Mark Lacey via swift-users]

> On Oct 6, 2016, at 4:53 AM, Toni Suter via swift-users 
>  wrote:
> 
> Hi,
> 
> Does someone know a good explanation / summary of Swift's overload resolution 
> rules?
> After reading https://github.com/apple/swift/blob/master/docs/TypeChecker.rst 
>  I understand
> that the overloading resolution happens as part of the constraint solving 
> step in the type 
> checker, but maybe there's a document somewhere, that explains the rules in 
> more detail?

I don’t know of any existing documentation for overload resolution. I was 
hoping to find some time to write something up in the next few months, but I’m 
not sure exactly when I might get to it.

In the meantime the best advice I can give is to dig into the code a bit to 
understand what’s going on. The type checker runs the constraint solver and 
collections all applicable solutions, and then compares these solutions to find 
a winner. That step is done in ConstraintSystem::findBestSolution() in 
CSRanking.cpp. That calls into ConstraintSystem::compareSolutions(), which is 
where most of the specific logic is. It checks overloads, and then checks the 
specific type bindings in each solution.

That code is reasonably well documented, so even without knowing a lot about 
the compiler internals I think it shouldn’t be too hard to follow.

Mark


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users