4 ms·

My worries about coding all these things into type systems is that this freezes the semantics at a time during development where one is still figuring out the i

by uecker 4mo ago

My worries about coding all these things into type systems is that this freezes the semantics at a time during development where one is still figuring out the ideal semantics. In any case, I wonder what you think about my experimental maybe type? https://godbolt.org/z/MTdj81841 https://godbolt.org/z/MTdj81841

bvrmn 4mo ago
I like maybe_value dereferences NULL with SIGILL and you have at least a backtrace with exact invalid access position.
- uecker 4mo ago
  Oh, you can get the information at compile time as well. https://godbolt.org/z/hTYbTE8j8 https://godbolt.org/z/hTYbTE8j8 (or https://godbolt.org/z/K1M68sY3Y https://godbolt.org/z/K1M68sY3Y but this will be tricky in a larger code base)
  - bvrmn 4mo ago
    That's the reason language/compiler should directly support optionality. You can't fool yourself and have to handle all cases: https://godbolt.org/z/4GqMdPej3 https://godbolt.org/z/4GqMdPej3
    - uecker 4mo ago
      So it seems exactly the same to me?
      - bvrmn 4mo ago
        Nice one. gcc/clang are smart enough to get .ok condition statically. I'm very curios how complex an expression could be.
tialaramex 4mo ago
> My worries about coding all these things into type systems is that this freezes the semantics at a time during development where one is still figuring out the ideal semantics. I don't get this part at all, especially in a language with static typing. It's completely normal for me to not be sure which type I need here and so I use a type alias, or if I'm even less sure I make a wrapper type so that it only has the properties I choose. So I don't see this "freezing" semantics any more than an identifier name would - we can just change it if we change our minds, no problem. To give a comparable example from elsewhere, when I'm still feeling out the problem I often write Rust's loop, the infinite loop which is Rust's only primitive looping structure (for and so are just sugar). That doesn't mean I write only weird odd-ball loops, but when I'm not sure the raw infinite loop is fine if I decided to consume all the Widgets in this Vec<Widget> like a for-loop but it's also OK if I decided to index through it, or do something entirely different. Rust's "clippy" will prompt me to write a more idiomatic while-let or for-each loop when I've nailed down the whole thing.

by uecker 4mo ago

bvrmn 4mo ago

I like maybe_value dereferences NULL with SIGILL and you have at least a backtrace with exact invalid access position.

uecker 4mo ago
Oh, you can get the information at compile time as well. https://godbolt.org/z/hTYbTE8j8 https://godbolt.org/z/hTYbTE8j8 (or https://godbolt.org/z/K1M68sY3Y https://godbolt.org/z/K1M68sY3Y but this will be tricky in a larger code base)
- bvrmn 4mo ago
  That's the reason language/compiler should directly support optionality. You can't fool yourself and have to handle all cases: https://godbolt.org/z/4GqMdPej3 https://godbolt.org/z/4GqMdPej3
  - uecker 4mo ago
    So it seems exactly the same to me?
    - bvrmn 4mo ago
      Nice one. gcc/clang are smart enough to get .ok condition statically. I'm very curios how complex an expression could be.

tialaramex 4mo ago

> My worries about coding all these things into type systems is that this freezes the semantics at a time during development where one is still figuring out the ideal semantics. I don't get this part at all, especially in a language with static typing. It's completely normal for me to not be sure which type I need here and so I use a type alias, or if I'm even less sure I make a wrapper type so that it only has the properties I choose. So I don't see this "freezing" semantics any more than an identifier name would - we can just change it if we change our minds, no problem. To give a comparable example from elsewhere, when I'm still feeling out the problem I often write Rust's loop, the infinite loop which is Rust's only primitive looping structure (for and so are just sugar). That doesn't mean I write only weird odd-ball loops, but when I'm not sure the raw infinite loop is fine if I decided to consume all the Widgets in this Vec<Widget> like a for-loop but it's also OK if I decided to index through it, or do something entirely different. Rust's "clippy" will prompt me to write a more idiomatic while-let or for-each loop when I've nailed down the whole thing.