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