4 ms·
Does Dart’s type system not support Non nullable types?? I can’t see why I would want to use a language without non-nullable types ... — is there a justificati
by breatheoften 8y ago
Does Dart’s type system not support Non nullable types?? I can’t see why I would want to use a language without non-nullable types ... — is there a justification for not supporting this somewhere — I’m curious why this wouldn’t have been an early requirement for the type system.
const FrogColor({
Key key,
@required this.color,
@required Widget child,
}) : assert(color != null),
assert(child != null),
super(key: key, child: child);
final Color color;
- thosakwe 8y agoAt this point in time, there's no support for NNBD, though people within the Dart team have proposed it. I can't speak on their behalf, though, as you can imagine.
- k__ 8y agoSome Dart dev wrote here on HN once there was a huge opposition in the dev team against non-nullable types, don't remember why tho
- thosakwe 8y agoThe post you're looking for, I think: https://news.ycombinator.com/item?id=14547826 https://news.ycombinator.com/item?id=14547826
- breatheoften 8y agoInteresting — thanks for the link! I really hope they aren’t too late to get non-nullable by default into the language as well... seems like it would influence a lot of the language design ... I personally found typescript almost impossible to use until turning on the non-nullable by default option and no implicit any (and really started liking it after). I see dart had “no implicit dynamic” — is that widely used in dart? I would turn that on with a quickness ... Reliable constraints were really important for me to figure out how to use the the optional typing model of typescript to my benefit. Maybe Dart’s programming model is simpler since it doesn’t maintain JavaScript compatibility... but my suspicion is that features like implicit-dynamic and nullable types will just make it harder to learn how to interpret compiler errors and harder to learn how to write good code in the language...