News for hackers. Stuff that matters.

A comment on Names are not type safety. Parent comment

Re:Names are not type safety by nyanpasu64 on Monday November 02, 2020 @05:00AM (#24966332)
> * You need to resist the temptation to add unsafe trapdoors in any other approach as well; this simply isn't a disadvantage that's in any way specific to using newtypes.

In fact, in some cases, it's useful to retain (redundant or invalid) state that's discarded in "correct by construction" data structures. For example, saving application configuration as Option<int> is easier for the application to read correctly (int value, bool present). However when a user is editing an Option<T> through a GUI (checkbox, number) pair, then unchecking the checkbox will set the value to None and discard the last entered value, which is a poor user experience in my view.

[ Parent | on HN ]
Re:Names are not type safety by IggleSniggle on Monday November 02, 2020 @11:52AM (#24970143)
This isn’t necessarily so, though. I don’t see why unchecking the checkbox can’t create an Option<T> that is passed (int value, bool false). It just means that you accept this as a valid construction state, and that it must therefore be handled.

I admit that I might be missing something fundamental to this discussion.

[ Parent | on HN ]
Re:Names are not type safety by nyanpasu64 on Monday November 02, 2020 @04:04PM (#24973336)
I meant to say "saving application configuration as Option<int> (either int value or None) is easier for the application to read correctly then a tuple (int value, bool present)."
[ Parent | on HN ]