Closed Hixie closed 6 years ago
Quite similar to #31865
It is indeed a duplicate of #31865. Dart 2 doesn't do inference on partial types, only on missing type arguments in expressions (basically in instance creation expressions and generic method calls).
It means that Set<int> s = new Set()
infers the type argument to the constructor, but Set s = new Set<int>()
does not do inference on the type annotation, so Set
here means Set<dynamic>
.
I don't think this is a duplicate. The Analyzer/Compiler error here isn't about <int>
- it's about LinkedHashSet
. @Hixie is asking that the Set
factory constructor be able to leak details about the concrete subtype that is returned from a factory ctor- though that seems like an anti-feature to me.
Isn't the default Set
type LinkedHashSet
?
https://github.com/dart-lang/sdk/blob/0b2684e6297217c690d082ce6f1d0e23215b5477/sdk/lib/core/set.dart#L49
... regardless, I don't see why this is an error, it should be valid to assign a Set<int>
to a Set<dynamic>
, just not the other way around. My error (#31865) is more about folks accidentally creating untyped collections when they think they are creating typed ones.
In @Hixie's case, his code looks totally valid, I think the CFE/Dart2 is doing the wrong thing (TM).
Isn't the default
Set
typeLinkedHashSet
?
Yes, but that is an implementation detail, it is not exposed through the signature. Nor, in my opinion, should it be.
I don't see why this is an error, it should be valid to assign a
Set<int>
to aSet<dynamic>
That is valid and is not the error.
The issue here is that the type of the variable is LinkedHashSet<dynamic>
and the initializer expression has type Set<int>
. A Set<int>
is not a super- or sub-type of LinkedHashSet<dynamic>
(they are both subtypes of Set<dynamic>
and both supertypes of LinkedHashSet<int>
, but the two types are not directly related. That makes the assignment not an implicit down-(or up-)cast.
Reading issue in #31865 again, it's not exactly the same problem, but it boils down to the issue that there is no inference for LinkedHashSet x = ...
, it always becomes LinkedHashSet<dynamic> x = ...
.
That's what's happening here, and it's currently working as intended.
The issue here is that the type of the variable is
LinkedHashSet<dynamic>
and the initializer expression has typeSet<int>
.
Right, this bug was requesting that the variable be typed using inference instead of defaulting to dynamic.
It seems unambiguous that that should be a
LinkedHashSet<int>
.