Transition to @safe by default

Quirin Schroll qs.il.paperinik at gmail.com
Wed Jul 31 17:21:38 UTC 2024


On Tuesday, 30 July 2024 at 20:17:52 UTC, Brad Roberts wrote:
> On 7/30/2024 12:19 PM, Richard (Rikki) Andrew Cattermole via 
> dip.ideas wrote:
>
> (this isn't directed at anyone in particular, and definitely 
> not Richard, just happens to be who wrote the below quote this 
> time)
>
>> Yes, I didn't state this but this is how I've always thought 
>> as it is based upon what the compiler can prove.
>
> It hasn't come up in a long time, so this is a reasonable time 
> to remind everyone that the compiler doesn't prove `@safe`-ty.  
> It checks for not-`@safe`-ty.  The logic is backwards from what 
> it 'should' be, imho. Instead of only allowing known to be safe 
> code, it blocks known to be problematic code.  Meaning that 
> omissions in the logic default to open rather than closed.

There sure is a difference, but it’s a didactic one, not a formal 
one. There is only a finite number of core-language operations. 
And I’m not talking about a formally finite, but humongous 
number, it’s really not that many. Formally, it makes no 
difference listing the allowed ones or the forbidden ones.


More information about the dip.ideas mailing list