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