-
Notifications
You must be signed in to change notification settings - Fork 132
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
Strong-mode analysis errors prevent DDC compilation #285
Comments
On it, ETA Monday. |
At least two pieces of code need rethinking / original authors' comment:
|
On the first question - somebody (maybe @munificent or maybe @NweiZ ?) recently fixed a similar issue, I'll try to track down what the solution there was. Note that you do still have the option of falling back on dynamic if needed, we just prefer to avoid it if possible. For the second question - again, I believe from a quick look that the code as written should work fine in strong mode/DDC - you may need to put an explicit cast on the return value, but the cast should succeed. If you're want to avoid the dynamic sends in the body, then you might need to structure this differently (e.g. define an abstract method _createWith which is the composition of _create and addAll). |
I believe you can fix the TreeSet constructor like so: factory TreeSet({Comparator<V> comparator}) {
if (comparator == null) {
comparator = (a, b) => (a as Comparable<V>).compareTo(b);
}
return new AvlTreeSet(comparator: comparator);
} This is statically unsound, but that's because the class exposes an API that isn't statically sound. It doesn't prevent you from doing To do something statically sound, I think you need distinct classes for a TreeSet that takes a Comparable type argument and one that takes a comparator. |
Note that this solution is only the right one if this is only supposed to work for things which actually implement Comparable. If you want it to work for anything that has a compareTo, you need to use the dynamic sends. |
Yes, |
I wish we could have different constraints on different constructors. Then we could do this (pretending TreeSet was not abstract): class TreeSet<V> implements Set<V> {
factory TreeSet<V extends Comparable>() => new TreeSet.withComparator(_comparableComparator);
TreeSet<V>.withComparator(Comparator<V> comparator) { ... }
} Since we don't, at least we should add to the docs that if no Comparator is provided, then V must implement Comparable, but I actually like Bob's solution of different classes. edit: My assumption is that anyone needing the strong-mode compliant TreeSet can use a new version. Quiver really needs to go 1.0 anyway (I'm really ignorant of any progress towards that by now). |
@justinfagnani I think you could already write a static generic method that does what you describe above (you don't get to use the factory syntax though). I can't immediately think of any problems with supporting something like that for factory constructors as well - maybe an idea to keep in mind for future. |
Fixed by #290 |
The following list of strong-mode errors prevent code that depend on
package:quiver
from being compiled with DDC.(ran
dartanalyzer --strong
find lib -name '*.dart'| sort -u
with SDK version1.16.0-dev.0.0
)The text was updated successfully, but these errors were encountered: