http://d.puremagic.com/issues/show_bug.cgi?id=9463
--- Comment #4 from [email protected] 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: -------
