http://d.puremagic.com/issues/show_bug.cgi?id=7432
--- Comment #12 from Stewart Gordon <s...@iname.com> 2013-08-18 17:00:48 PDT --- (In reply to comment #11) >> In the absence of any explanation of what pure means applied to >> variables, I can only be assumed that pure cannot be applied to >> variables, and therefore any attempt to apply pure to a variable >> is supposed to fail with a compile error. > > Except that in most cases, an invalid attribute doesn't result in a > compilation error - it's ignored. You're talking about what the compiler actually does, which is a different matter from what the spec indicates it should do. > The argument for this is generally that it helps generic code, and > it makes it easier to do stuff like > > attribute: > ... > > or > > attribute > { > } > > without caring about the items that it doesn't apply to. You mean it's easier to implement if (a), (b) and (c) in the description of bug 3118 are *always* either all legal or all illegal? To me there doesn't seem to be much in it. > For instance, you can do that with attributes like @safe or > @trusted, which have zero effect on variables and yet have lots of > variables declared in that code. The same goes for pure. Maybe. And you could possibly argue that the criteria for purity are trivially true for variables (since a variable cannot read or write state, or call functions, or override, or perform I/O), but the spec speaks only of pure _functions_. > I don't see a good argument for > > pure foo = "hello"; > > being legal though unless the argument is that all invalid > attributes are ignored (which is not the case). Indeed, the point of pure seems to be to indicate that something is suitable for use within a purely functional programming paradigm. So unless we make pure equivalent to immutable when applied to variables.... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------