It's cropped up on a number of occasions.  And again in the comments on
http://d.puremagic.com/issues/show_bug.cgi?id=2830
http://d.puremagic.com/issues/show_bug.cgi?id=1441
which are essentially the same as each other.  The basic matter of debate is: If an attribute is applied to something to which it is not applicable, should it be an error, silently ignored or what?

There are a number of cases to consider:

(a) Attributes that state what is already implied by the context.  For example, module-level functions are effectively both static and final.

(b) Attributes that don't make sense in the context.  For example, trying to apply scope to a function.

(c) Attributes that make sense in the context but are nonetheless not actually applied.  The issue brought up in the above bug reports is an example - actual compiler behaviour even _contradicts_ the fact that a protection attribute has been specified.

One recent comment referred to inapplicable attributes generally as "'pointless' attributes".  This may be a valid label for (a), but certainly not (b) or (c).


At the moment, the problem seems to be that the compiler is silently ignoring many cases of (a), (b) and (c) alike.  Some people argue that the spec doesn't forbid such use of inapplicable attributes explicitly, and so the compiler's treatment of these cannot be called a bug.

I argue that this isn't right.  Nothing I've managed to find in the spec states or implies that such obviously wrong code is allowed.  So, by applying common sense, one would conclude that it isn't allowed.


Perhaps what complicates matters further is that D has three ways of specifying attributes:

(i) as part of the declaration itself
(ii) in a block delimited by { }
(iii) with a colon to apply to everything that follows until the end of the scope

It would be annoying to have to avoid (iii) just because you want to declare something of a kind to which the attribute is inapplicable later in the file.  This may also apply to some degree to (ii), but any use of an inapplicable attribute (at least of case (b) or (c)) by (i) is bound to be a mistake.

There are also attributes, such as align and (I think) extern, for which applying to a compound type is equivalent to applying to all of its members.  This should be allowed wherever it makes sense to the context, since it would be annoying (for example) to be prevented from declaring an alignment on a struct as a whole just because it contains functions.


Basically, what we need to do is:

- Eradicate all cases of (c), fixing it so that the attribute actually works in such cases.
- Make sure all cases of (b) generate a compile error when used by (i).
- Define some clear rules on when an attribute may be used by (ii) or (iii) if it is inapplicable to some of the entities to which the programmer has tried to apply it.


Comments?

Stewart.

Hello Stewart,

> Perhaps what complicates matters further is that D has three ways of
> specifying attributes:
> 
> (i) as part of the declaration itself

I more or less only use this.

> (ii) in a block delimited by { }

If I remembered that this one even exists, I might use it.

> (iii) with a colon to apply to everything that follows until the end
> of
> the scope

I'd be just tickled if this one were just dropped.

Just my $0.02 because that might make things less complex.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:grtr90$1hlh$1@digitalmars.com...
> It's cropped up on a number of occasions.  And again in the comments on
> http://d.puremagic.com/issues/show_bug.cgi?id=2830
> http://d.puremagic.com/issues/show_bug.cgi?id=1441
> which are essentially the same as each other.  The basic matter of debate
> is: If an attribute is applied to something to which it is not applicable,
> should it be an error, silently ignored or what?
>
> There are a number of cases to consider:
>
> (a) Attributes that state what is already implied by the context.  For example, module-level functions are effectively both static and final.
>
> (b) Attributes that don't make sense in the context.  For example, trying to apply scope to a function.
>
> (c) Attributes that make sense in the context but are nonetheless not actually applied.  The issue brought up in the above bug reports is an example - actual compiler behaviour even _contradicts_ the fact that a protection attribute has been specified.
>
>[snip]
>
> Perhaps what complicates matters further is that D has three ways of specifying attributes:
>
> (i) as part of the declaration itself
> (ii) in a block delimited by { }
> (iii) with a colon to apply to everything that follows until the end of
> the scope
>
>[snip]
>
> Basically, what we need to do is:
>
> - Eradicate all cases of (c), fixing it so that the attribute actually
> works in such cases.
> - Make sure all cases of (b) generate a compile error when used by (i).
> - Define some clear rules on when an attribute may be used by (ii) or
> (iii) if it is inapplicable to some of the entities to which the
> programmer has tried to apply it.
>

Absolutely. I think it boils down to this: If something seems to work, it should work as expected. Things should either just "work" or "not work". _Never_ "it works, but does something completely different".

I think this ticket I filed might also be another case of the same issue: http://d.puremagic.com/issues/show_bug.cgi?id=2775

I've never even looked to see if the language definition explicitly allows/forbids/doesn't-address using "private" on templates/structs/classes/unions. But for such a basic and conceptually simple language feature, I shouldn't even need to. Don't force me to be a language lawyer to use such simple things properly: If I stick "private" in front of something, and the compiler *accepts* it, it should "just f*^&*%^* work". If for some bizarre reason private templates/structs/classes/unions aren't supposed to be allowed (which I *really* hope is not the case), then dagnabbit, the compiler needs to speak up. After all, it is the role of the compiler to raise an error when the programmer tries to do something that isn't allowed, and not to just silently make up some alternative behavior (if I wanted to put up with that kind of "principle of maximum silent surprises" crap I'd use a scripting language).

Until now I just assumed these were a compiler bugs, but if this "let's let the programmer *think* this is working the way they intended" behavior is intentional just for the sake of Stewart's (ii) and (iii), well then that's terrible and absolutely needs to change.

"BCS" <none@anon.com> wrote in message news:a6268ff4a7a8cb89c641dc84ac@news.digitalmars.com...
> Hello Stewart,
>
>> Perhaps what complicates matters further is that D has three ways of specifying attributes:
>>
>> (i) as part of the declaration itself
>
> I more or less only use this.
>
>> (ii) in a block delimited by { }
>
> If I remembered that this one even exists, I might use it.
>
>> (iii) with a colon to apply to everything that follows until the end
>> of
>> the scope
>
> I'd be just tickled if this one were just dropped.
>
> Just my $0.02 because that might make things less complex.
>

I'm kind of on the fence about whether (ii) or (iii) should be allowed. I haven't used (iii) since I was using C/C++ regularly (ie, almost 10 years ago). But I think the only real reason I switched from (iii) to (i) was because of the time I spent with Java and C#. I would never want to get rid of (i), but I keep debating with myself about occasional usage of (ii) or (iii).

BCS wrote:
> Hello Stewart,
> 
>> Perhaps what complicates matters further is that D has three ways of
>> specifying attributes:
>>
>> (i) as part of the declaration itself
> 
> I more or less only use this.
> 
>> (ii) in a block delimited by { }
> 
> If I remembered that this one even exists, I might use it.
> 
>> (iii) with a colon to apply to everything that follows until the end
>> of
>> the scope
> 
> I'd be just tickled if this one were just dropped.
> 
> Just my $0.02 because that might make things less complex.
> 
> 

I use all three all the time. It's a nice mini feature of D. No reason to remove it.

And if you want to remove complexity, start with the bigger chunks of the D language.

Hello grauzone,

> BCS wrote:
> 
>> Just my $0.02 because that might make things less complex.
>> 
> And if you want to remove complexity, start with the bigger chunks of
> the D language.
> 

complexity re the OP's point, not just in general. if only (i) is allowed then there isn't (much of) a case for allowing inapplicable attribute (IMHO).

Stewart Gordon Wrote:

> At the moment, the problem seems to be that the compiler is silently ignoring many cases of (a), (b) and (c) alike.  Some people argue that the spec doesn't forbid such use of inapplicable attributes explicitly, and so the compiler's treatment of these cannot be called a bug.
> 
> I argue that this isn't right.  Nothing I've managed to find in the spec states or implies that such obviously wrong code is allowed.  So, by applying common sense, one would conclude that it isn't allowed.

Such mood was always in the spec: "AlignAttribute is ignored when applied to declarations that are not structs or struct members".

Kagamin wrote:
> Stewart Gordon Wrote:
> 
>> At the moment, the problem seems to be that the compiler is silently ignoring many cases of (a), (b) and (c) alike.  Some people argue that the spec doesn't forbid such use of inapplicable attributes explicitly, and so the compiler's treatment of these cannot be called a bug.
>>
>> I argue that this isn't right.  Nothing I've managed to find in the spec states or implies that such obviously wrong code is allowed.  So, by applying common sense, one would conclude that it isn't allowed.
> 
> Such mood was always in the spec: "AlignAttribute is ignored when applied to declarations that are not structs or struct members".

I never saw that before. So it doesn't work for class members? And it won't change the alignment of unions if applied to union members (by changing the maximum alignment of the members)?

On Mon, Apr 13, 2009 at 2:05 PM, Frits van Bommel <fvbommel@remwovexcapss.nl> wrote:
> Kagamin wrote:
>>
>> Stewart Gordon Wrote:
>>
>>> At the moment, the problem seems to be that the compiler is silently
>>> ignoring many cases of (a), (b) and (c) alike.  Some people argue that the
>>> spec doesn't forbid such use of inapplicable attributes explicitly, and so
>>> the compiler's treatment of these cannot be called a bug.
>>>
>>> I argue that this isn't right.  Nothing I've managed to find in the spec states or implies that such obviously wrong code is allowed.  So, by applying common sense, one would conclude that it isn't allowed.
>>
>> Such mood was always in the spec: "AlignAttribute is ignored when applied to declarations that are not structs or struct members".
>
> I never saw that before. So it doesn't work for class members? And it won't change the alignment of unions if applied to union members (by changing the maximum alignment of the members)?
>

align is defined in terms of the companion C compiler.

align(16) int foo; does not guarantee that foo.offsetof is aligned to 16 bytes. Since C doesn't have D classes, the align attribute makes little sense here.

Frits van Bommel wrote:
> Kagamin wrote:
<snip>
>> Such mood was always in the spec: "AlignAttribute is ignored when applied to declarations that are not structs or struct members".
> 
> I never saw that before. So it doesn't work for class members?

http://www.digitalmars.com/d/1.0/class.html
"The D compiler is free to rearrange the order of fields in a class to optimally pack them in an implementation-defined manner. Consider the fields much like the local variables in a function - the compiler assigns some to registers and shuffles others around all to get the optimal stack frame layout. This frees the code designer to organize the fields in a manner that makes the code more readable rather than being forced to organize it according to machine optimization rules. Explicit control of field layout is provided by struct/union types, not classes."

> And it won't change the alignment of unions if applied to union members (by changing the maximum alignment of the members)?

I'm not sure what you mean....

But there seem to be a few issues with the behaviour of align.  I'll have to investigate....

Stewart.