Trusted Manifesto

Zach the Mystic via Digitalmars-d digitalmars-d at puremagic.com
Tue Feb 10 08:14:25 PST 2015


On Tuesday, 10 February 2015 at 16:04:05 UTC, Marc Schütz wrote:
> On Tuesday, 10 February 2015 at 15:57:28 UTC, Zach the Mystic 
> wrote:
>> On Tuesday, 10 February 2015 at 15:49:24 UTC, Zach the Mystic 
>> wrote:
>>>>> As already pointed out in the other thread, there is a 
>>>>> non-breaking variant of (3):
>>>>>
>>>>> 3a. Keep named @trusted functions, allow @system blocks 
>>>>> inside them, but only treat those with @system blocks with 
>>>>> the new semantics.
>>>>
>>>> But they *have* no semantics without disallowing @system 
>>>> code in the rest of the @trusted function.
>>>
>>> Wait a second... you're totally right. That is a cool 
>>> solution. The only hiccup is that it might be hard to 
>>> implement in the compiler because of flow tracking (i.e. the 
>>> error comes before the @system block, forcing a recheck of 
>>> all preceding functions.).
>>
>> I'm sorry I misread you at first -- this is actually really 
>> cool (notwithstanding the hiccup)!
>
> No problem!
>
> At first I thought it was only a nice deprecation path, but I 
> realised that the intermediate stage could even be kept 
> indefinitely.

Eventually the error should be the default, I say, but even then, 
a compiler switch can be kept around indefinitely which turns the 
error off.

> It probably wouldn't be too complicated to implement, because 
> semantic analysis already happens in several stages. I think 
> @safe checks happen relatively late, which means that there has 
> already been one complete traversal of the functions AST which 
> can take a note whenever it sees an @system block.

Well that's just jolly!


More information about the Digitalmars-d mailing list