@system blocks and safer @trusted (ST) functions

[Paul Backus]

On Wednesday, 28 July 2021 at 11:12:14 UTC, Steven Schveighoffer 
wrote:
> On Monday, 26 July 2021 at 18:59:45 UTC, Paul Backus wrote:
>> The difference between POSIX `read` and `favoriteNumber` is 
>> that you *can* read the source code of `favoriteNumber`. It's 
>> literally right there, in the same module. That's the entire 
>> reason why you can be certain it returns `42`.
>>
>> If `favoriteNumber` and `favoriteElement` were in different 
>> modules, your argument would be correct, because 
>> `favoriteElement` could no longer be certain about which 
>> version of `favoriteNumber` it was calling.
>
> If you consider the source to be the spec, then that 
> contradicts your earlier suggestion that `favoriteNumber` can 
> be changed -- its source is the spec, so changing the source to 
> return something other than 42 will violate the spec.
>
> If you consider the source to be the spec *and* you think 
> changing the spec at will is OK, then we have different 
> philosophies on what a code review and "good software" means.

Again, I am in 100% in agreement with you that `favoriteElement` 
is not "good software" and should not pass code review. I have 
never claimed otherwise. (In fact, I spent the rest of that post 
talking about how we can reject functions like `favoriteElement` 
in code review!)

That does not change the fact that in the *current version* of my 
example module, `favoriteElement` is memory safe--meaning, it 
cannot possibly cause undefined behavior when called with [safe 
values][1]. It is possible for bad software to be memory safe.

It seems to me like we have been talking past each other for most 
of this discussion, with differences in background assumptions 
obscured by words like "correct", "valid", "safe", etc. In the 
future, I will try to be much more careful about defining my 
terms.

[1]: https://dlang.org/spec/function.html#safe-values