alias enum int e;

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;

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

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!

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.

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?

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.

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

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

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.