Inconsistent ambiguity issues.

General Issues and Bug Reporting
, ,
1

Please select what you are reporting on:

Verse

What Type of Bug are you experiencing?

Verse

Summary

Look at the following examples.

interface_a := interface:
interface_b := interface:
Foo(:interface_a): void = ()
Foo(:interface_b): void = ()

Foo(:interface_a) and Foo(:interface_b) are not allowed because something could be a subtype of both.
The compiler won’t allow it.

class_a := class:
class_b := class:
Foo(:class_a): void = ()
Foo(:class_b): void = ()

Foo(:class_a) and Foo(:class_b) are allowed despite false being a subtype of both.
The compiler will allow it.

Foo(:[]int): void = ()
Foo(:[]char): void = ()

Foo(:[]int) and Foo(:[]char) are not allowed because []false being a subtype of both.
The compiler won’t allow it.

Steps to Reproduce

Copy and paste the snippets above into your code and check it for yourself.

Expected Result

All three of these examples should work totally fine.

Observed Result

The compiler is inconsistent - allows some and not others, even tho the exact same thing applies to all three examples.

Platform(s)

All

2

I believe these would require unique tags to be comparable for your example to hold up.
I’m not sure but I know that classes aren’t comparable without a unique tag, so my mistake if this is not what you’re expressing here.

3

The status of UCB-1312 incident has been moved from ‘Needs Triage’ to ‘Closed’. Resolution Reason: ‘By Design’

4

Ah, no, that’s unrelated to <unique> or comparables in general.

5

Ah okay. Interesting, I try to understand the more advanced programming stuff but I never coded before this. I’ll keep an eye on this to see whre it goes and what i can learn from it.

6

This literally makes no sense. Why would you treat overloading of arrays and interfaces that much worse than overloading classes…
Every reason for or against overloading applies to all three, so why would you handle it different.