3 ms·

I'm still more in favor of Option<T>

• martinsnow 2y ago
  Ew.
  • revskill 2y ago
    What does this mean ?
    • agumonkey 2y ago
      preference for added syntax instead of generic type I assume understandable in a way but I'm more fond of types vs syntax
• jeltz 2y ago
  Same, since nullability should be the exception then it is a good thing that is more verbose.
  • masklinn 2y ago
    This is perfectly logical in languages which have defaulted to opt-in nullability from the start, but it’s heinous and would actively hinder migration in languages which are trying to transition (or something similar e.g. Swift is non-nullable but objc interop was a major design factor, and objc has absolutely ubiquitous nullability).
    • jeltz 2y ago
      Not sure why you think it is heinous but I agree with the other part. In a language where null was the default I do not see a migration path where Option<T> can be used. Option<T> only works for languages where nullability was never a thing. The issue is obvious in how useless the Optional<T> class in Java is.
      • shepherdjerred 2y ago
        How is Optional useless? I've found it to be very ergonomic, though I do wish there was more support for it in the standard library.
• haspok 2y ago
  (An Option<T> itself can still be null...) With an Option, you need to .orElse() if you want to access the value it is holding (or map it). With null restricted types you do this check upfront, when you convert a T to a T!, and from then you can use the value without any gymnastics. It is a bit like virtual threads vs effect systems, the monadic IO type gives you far more power, but with great power comes great responsibility (and complexity). If you can get compiler support for the simpler solution that will always be prefereable.