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



--- Comment #10 from Stewart Gordon <smjg@iname.com> 2013-08-18 13:54:30 PDT ---
Yes, that was the essence of bug 3118.  It seems Walter wontfix'd it because he feels each attribute needs to be considered individually.

The only explanation of pure that I've managed to find in the specs relates to
functions.
http://dlang.org/function.html#pure-functions

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.

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

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



--- Comment #11 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-08-18 14:14:17 PDT ---
> 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. 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. 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.

I don't know what the best way to handle this is given that sometimes it is useful to have an attribute ignored when it doesn't apply, but it also can be quite misleading, and the case where a symbol is explicitly marked with an attribute and then that attribute is ignored is particularly bad. Maybe we could petition for that particular case to always be an error (which would cover this bug), but I don't see it changing for attribute: or attribute {}. 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).

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

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



--- Comment #12 from Stewart Gordon <smjg@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: -------

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



--- Comment #13 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-08-18 17:17:33 PDT ---
> You're talking about what the compiler actually does, which is a different matter from what the spec indicates it should do.

Honestly, it really doesn't matter what the spec says. In general, if there's a disagreement between the spec and the compiler, the spec loses. The spec and the compiler should be in agreement, but the fact that the spec says something doesn't necessarily mean much. The spec is generally written after the fact to match the compiler rather than the compiler being written to match the spec. So, yes, the situation there needs to be improved, but complaining that the compiler is wrong because it doesn't match the spec will likely get you nowhere.

> 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....

pure makes no sense whatsoever on variables. Neither do @safe, @trusted, or nothrow. The fact that you can at least sometimes marks variables that way is a side effect of the fact that the compiler tends to ignore invalid attributes. I really don't think that we should even consider making it so that any of those make sense on variables. All we should be doing is determining where the compiler should ignore invalid attributes and where it should give an error, and then we need to make sure that both the spec and the compiler agree.

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

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



--- Comment #14 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-08-18 21:48:57 PDT ---
(In reply to comment #10)
> Yes, that was the essence of bug 3118.  It seems Walter wontfix'd it because he feels each attribute needs to be considered individually.
> 
> The only explanation of pure that I've managed to find in the specs relates to
> functions.
> http://dlang.org/function.html#pure-functions
> 
> 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.

This is not a good way of reasoning.

Also, as described above there are cases like in attribute: or attribute {} where ignoring storage class helps.

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

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



--- Comment #15 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-08-18 21:52:09 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. 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. 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.
> 
> I don't know what the best way to handle this is given that sometimes it is useful to have an attribute ignored when it doesn't apply, but it also can be quite misleading, and the case where a symbol is explicitly marked with an attribute and then that attribute is ignored is particularly bad. Maybe we could petition for that particular case to always be an error (which would cover this bug), but I don't see it changing for attribute: or attribute {}. 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).

Perhaps allow to apply storage classes to variables in block declarations like attribute: or attribute { } and ban them in single variable declarations?

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

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



--- Comment #16 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-08-18 22:59:59 PDT ---
> Perhaps allow to apply storage classes to variables in block declarations like attribute: or attribute { } and ban them in single variable declarations?

That's basically what I was thinking (though I would want to apply that to all symbols, not just variables). At the moment, I can't think of why that would be a problem (though someone may be able to come up with a reason why it would be).

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

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



--- Comment #17 from Stewart Gordon <smjg@iname.com> 2013-08-18 23:05:47 PDT ---
(In reply to comment #13)
>> You're talking about what the compiler actually does, which is a different matter from what the spec indicates it should do.
> 
> Honestly, it really doesn't matter what the spec says.  In general, if there's a disagreement between the spec and the compiler, the spec loses.

What you're basically saying here is that the language is _defined_ by the compiler, and consequently the compiler has no bugs.

So what is the meaning of the word "spec" in your mind?

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

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



--- Comment #18 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-08-18 23:30:45 PDT ---
> What you're basically saying here is that the language is _defined_ by the compiler, and consequently the compiler has no bugs.

No, I'm not saying that the compiler has no bugs. If there is a disagreement between the spec, the compiler, or TDPL, then it has to be discussed which is correct, but in general, TDPL wins, then the compiler, and then the spec. Yes, the spec _should_ define what the language is, but it's not that precise or that complete, and the language is still under enough development that the spec has to change from time to time even if it's compeletely correct, and the reality of the matter is that the spec is often incorrect if nothing else because it frequently doesn't get updated properly when language design decisions are made, whereas the compiler almost always does get updated.

It's not like the spec was written, and then a compiler was written to match it. The language has evolved over time, and on the whole, the compiler has defined what the language is, and Walter has defined what the language is supposed to be when questions come up. The spec attempts to define what the language is based on that, but it doesn't always manage it, primarily because it isn't maintained well enough.

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

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


safety0ff.bugz <safety0ff.bugz@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aliloko@gmail.com


--- Comment #19 from safety0ff.bugz <safety0ff.bugz@gmail.com> 2013-10-30 16:23:17 PDT ---
*** Issue 11391 has been marked as a duplicate of this issue. ***

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