[discreteevent]

I get that. (Another way to do it at run time is capabilities). What I don't like is calling this "unsafe". We know that use after free is never something anyone intended. We don't know that about opening a socket. If we take the attitude that any effect is unsafe then soon we will feel we have to control every one of them. If I have to control everything someone else does then I might as well do it myself (i.e. you eventually start to leak the implementation details and lose flexibility). Call it contracts or capabilities or something but not unsafe.

[chriswarbo]

Use-after-free is bad. "Unsafe" isn't the same as bad; unsafe means "could be bad". The reason that is a useful definition for unsafe, is that it allows us to define safe as "definitely not bad".

In Haskell, a function like 'Int -> String' is safe (definitely not bad). A function like 'Int -> IO String' is unsafe (it might be bad; we hope not). If it were possible to specify "bad" via the type system (like the type of use-after-free) then we would want that to be a type error (like it is in Rust).

[discreteevent]

I don't know. Int -> String could be bad if the algorithm that calculates the value of the string is bad. But anyway I suppose I don't like changing the use of language where "unknown" now becomes "unsafe". Unsafe to me means that I know something about it. If I know nothing about it then it is neither safe nor unsafe. It's just unknown. Why not call it that? Otherwise we have two words for the same thing and have made our language more imprecise. (Alternatively if we take the attitude that something unknown could be good then we could argue that we call it safe).

[chriswarbo]

> I suppose I don't like changing the use of language where "unknown" now becomes "unsafe".

I don't think that's changing the use of language at all. For example, playing one round of russian roulette is 'unsafe'; even though (a) we don't know if it will have a bad outcome or not, and (b) the chance of a good outcome is much higher than that of a bad outcome.

[PeterisP]

I do believe that "unknown" should mean "unsafe". Safe means that you can rely on it, if you don't know anything about it then from a safety perspective this must be treated as unsafe.

[fiddlerwoaroof]

Except this isn’t true. I can embed arbitrary side effects in any line of Haskell code with something like

    foo :: Int -> String
    foo x = seq
            (unsafePerformIO $
              println “pwned”)
            (show x)

[kqr]

Yes, we know unsafePerformIO exists, but nobody really uses it, it's clearly "unsafe", you can have your build chain scream at its occurrence, and... fast and loose reasoning is morally correct[1].

[1]: https://dl.acm.org/doi/10.1145/1111320.1111056

[chriswarbo]

FYI this sort of 'backdoor' can be forbidden using the "safe haskell" extension in GHC:

https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...