[Issue 9463] make @safe "non-escapable"

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=9463



--- Comment #4 from jfanatiker at gmx.at 2013-02-06 16:11:11 PST ---
(In reply to comment #3)
> The only difference between using : and {} with attributes is that {} has an
> end to its scope, whereas : only ends if it's overriden by a conflicting
> attribute. Differentiating between the two in terms of what they affect seems
> like a really bad idea to me.
> 
> I'd argue that it's up to the functions being mixed in to guarantee that
> they're @safe, not the code that's mixing them in. And attributes get ignored
> all the time if they don't apply. Relying on attributes which are applied
> globally with : or {} is often a bad idea precisely because dmd will happily
> ignore attributes that it doesn't think are applicable.

Yeah, but what if you can not trust the code you are mixing in to declare it
self @safe, like in the example with the imported configuration. You could
validate the code, by greping for @system and @trusted but this would be pretty
unreliable, especially with mixins. So you would end up writing your own D
parser.

The goal of this feature is to make D more viable for problems one would
usually pick a scripting language.

> 
> > I personally would prefer the simple consistent rule, that you can not weaken
> > @safe, @trusted once you declared it. If you don't want the whole file @safe,
> > then don't say so.
> 
> Except that that's always up to the function. You can't weaken @safe because it
> was never applied in the first place. All that attribute{} or attribute: do is
> mark symbols with those attributes if applicable, and it doesn't apply if
> there's a conflicting attribute. The same happens with access levels.
> 
> private {
> public int foo() { return 42; }
> }
> 
> dmd quite happily makes foo public. There generally are no special cases with
> attributes in D (and I can't think of _any_ at the moment). If there were, it
> would be required to put const on the right-hand side of a function rather 

Thanks for this good explanation. But maybe there is a good solution, simply
say that @safe is not applicable if a function was previously marked @system or
@trusted. (Might be a problem, because @system is the default, but this could
easily be worked around by internally distinguishing between explicitly
assigned @system and implicit @system).

So it bails down to the meaning of "applicable".

I just think that this would greatly enhance the usefulness of @safe code.
(Easy and efficient sandboxing)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------