Would be awesome to have Koka's side-effect system in D.

See https://koka-lang.github.io/koka/doc/book.html#sec-semantics-of-effects.

On Wednesday, 27 March 2024 at 07:47:02 UTC, Per Nordlöw wrote:

Don't we have a pretty good appromixation of pure, well, pure? St can also be easily represented by giving the state object as an extra ref parameter.

As for total, I don't think it's practical. That would mean no divisions, no assertions, no normal array indexing.

Besides, often you do have values that are representable by types of the parameters but that indicate a bug in the caller side if they're ever passed. You'd want a total function only if what you're doing actually makes sense for all the possible (@safe) values. If that isn't the case, asserting on invalid values is the right thing to do as Walter always says, not coming up with some cover-up return value to make the function total.

For example, if you have a function computing an average over an integer array, it'd be a bad idea to make that total since you would have to return a made-up value for an empty array instead of asserting.

While there are certainly some cases where you could reasonably make a function total, like bitwise boolean logic, on the whole it's just not practical to attempt programming in a crash-safe manner in D. I don't have enough experience in Haskell to judge if it's practical there, but it at least gets closer. For the idea to be worthwhile, you need to be able to limit the possible values of variables with types in the majority of the cases. This means non-nullable and nullable types for everything, ints with value range information, float that can't be NaN, non-empty types for ranges, and so on. And it needs to be extremely easy to translate those types to each other.

D does not have that kind of type system and it doesn't look like a good direction of development for it. For example, because all D types need an .init value, it means a general-purpose non-empty range type would be very difficult to define in a practical manner. The language simply works very differently from what total programming style would ask for.