www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - since when was this valid syntax?

reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
alias enum int e;
Sep 08 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/08/2012 04:11 PM, Ellery Newcomer wrote:
 alias enum int e;

It is valid according to the grammar and DMD ignores meaningless attributes. scope shared disable trusted package final override deprecated extern __gshared synchronized pure nothrow ref static abstract immutable alias auto final override deprecated extern __gshared synchronized enum pure nothrow ref static abstract safe disable scope int e;
Sep 08 2012
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Timon Gehr:

 It is valid according to the grammar and DMD ignores 
 meaningless attributes.

Do you know why? Is it just a unfinished part of dmd, or Walter believes this is an acceptable design for a compiler? In years I have never heard a comment from him on this bad situation. Bye, bearophile
Sep 08 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/08/2012 06:44 PM, bearophile wrote:
 Timon Gehr:

 It is valid according to the grammar and DMD ignores meaningless
 attributes.

Do you know why?

No reason.
 Is it just a unfinished part of dmd, or Walter believes
 this is an acceptable design for a compiler?

Jonathan would say he has more important things to do.
 In years I have never heard a comment from him on this bad situation.

I'd design it differently as well. But this is the kind of thing that can be ignored indefinitely without hurting the programmer more than once. A similar issue is that the compiler actually won't detect clashing function overloads, leaving the error report up to the linker.
Sep 08 2012
prev sibling next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Saturday, 8 September 2012 at 16:00:44 UTC, Timon Gehr wrote:
 scope shared  disable  trusted package final override 
 deprecated extern __gshared synchronized pure nothrow ref 
 static abstract immutable alias auto final override deprecated 
 extern __gshared synchronized enum pure nothrow ref static 
 abstract  safe  disable scope int e;

Time to hold an obfuscated D contest!
Sep 08 2012
prev sibling next sibling parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Saturday, 8 September 2012 at 16:00:44 UTC, Timon Gehr wrote:
 On 09/08/2012 04:11 PM, Ellery Newcomer wrote:
 alias enum int e;

It is valid according to the grammar and DMD ignores meaningless attributes. scope shared disable trusted package final override deprecated extern __gshared synchronized pure nothrow ref static abstract immutable alias auto final override deprecated extern __gshared synchronized enum pure nothrow ref static abstract safe disable scope int e;

How dmd's parser is written if it allows such things?
Sep 08 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/08/2012 09:25 PM, Maxim Fomin wrote:
 On Saturday, 8 September 2012 at 16:00:44 UTC, Timon Gehr wrote:
 On 09/08/2012 04:11 PM, Ellery Newcomer wrote:
 alias enum int e;

It is valid according to the grammar and DMD ignores meaningless attributes. scope shared disable trusted package final override deprecated extern __gshared synchronized pure nothrow ref static abstract immutable alias auto final override deprecated extern __gshared synchronized enum pure nothrow ref static abstract safe disable scope int e;

How dmd's parser is written if it allows such things?

It's the grammar that allows this. Every parser that follows the grammar would accept this.
Sep 08 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Saturday, 8 September 2012 at 18:16:33 UTC, Chris Cain wrote:
 Time to hold an obfuscated D contest!

Hmmm... A little more difficult compared to C, since you don't have the pre-processor. I recall TCC (Tiny C Compiler) was originally done in a obfuscation contest where he got the main features he wanted, then added until he ran out of space. After the contest he finished it as a full project. If we DID do it, what would the rules be? Depending on what they are it could be quite curious. Probably looking at 2-4k file; But not including whitespace you could make for an interesting look. I've seen quite often where they will make the source part of a visual display. Something like this. (Spam checker got stuck so link instead) http://dpaste.dzfl.pl/623336f9 I would think common imports of modules could be ignored from the source (but aliases afterwards would not. Anything commented (Not part of code) could be ignored. Hmmm...
Sep 08 2012
prev sibling next sibling parent Maxim Fomin <maxim maxim-fomin.ru> writes:
2012/9/8 Timon Gehr <timon.gehr gmx.ch>:
 On 09/08/2012 09:25 PM, Maxim Fomin wrote:
 On Saturday, 8 September 2012 at 16:00:44 UTC, Timon Gehr wrote:
 On 09/08/2012 04:11 PM, Ellery Newcomer wrote:
 alias enum int e;

It is valid according to the grammar and DMD ignores meaningless attributes. scope shared disable trusted package final override deprecated extern __gshared synchronized pure nothrow ref static abstract immutable alias auto final override deprecated extern __gshared synchronized enum pure nothrow ref static abstract safe disable scope int e;

How dmd's parser is written if it allows such things?

It's the grammar that allows this. Every parser that follows the grammar would accept this.

Where is this grammar been defined? It looks more like a bug.
Sep 08 2012
prev sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 09/08/2012 09:01 AM, Timon Gehr wrote:
 On 09/08/2012 04:11 PM, Ellery Newcomer wrote:
 alias enum int e;

It is valid according to the grammar

I don't believe you. Show me the derivation.
Sep 09 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/10/2012 07:07 AM, Ellery Newcomer wrote:
 On 09/08/2012 09:01 AM, Timon Gehr wrote:
 On 09/08/2012 04:11 PM, Ellery Newcomer wrote:
 alias enum int e;

It is valid according to the grammar

I don't believe you. Show me the derivation.

The grammar as shown on dlang.org indeed seems not to allow this, but it is out of date as it also wouldn't allow alias extern(C) void function() fun;
Sep 10 2012
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, September 08, 2012 20:25:38 Timon Gehr wrote:
 Jonathan would say he has more important things to do.

If someone else did it and had good enough arguments why the change should be made, then it might make it in, but on top of Walter's time issues, this strikes me as the sort of thing that he normally lets linger and will probably disagree on with folks like Bearophile anyway (though I don't recall him ever taking a stand on the issue). David Simcha has argued in the past that it's actually better for generic code if it's left this way (since otherwise, conflicting attributes would mean that you'd have to use static ifs and the like to make the code valid). Walter may or may not agree with that and may or may not have other reasons why it should be the way that it is. But my guess is that he won't really see it as a problem. I do think that it would be nice if the situation were improved, but I also really doubt that it's going to be changed any time soon without some other than Walter doing it (and that's still assuming that they can convince Walter, which may or may not be easy). - Jonathan M Davis
Sep 08 2012