[Issue 19056] UDAs can be added to imports but not retrieved

Jul 06, 2018

RazvanN

Jul 07, 2018

Seb

Jul 08, 2018

Jul 08, 2018

Jul 09, 2018

Jul 09, 2018

Jul 11, 2018

Jul 13, 2018

Dec 17, 2022

Dec 13

dlangBugzillaToGithub

https://issues.dlang.org/show_bug.cgi?id=19056 RazvanN <razvan.nitu1305@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |razvan.nitu1305@gmail.com --- Comment #1 from RazvanN <razvan.nitu1305@gmail.com> --- It seems that UDAs do not work with aliases and `@X import y = std.stdio;` creates an alias behind the scenes. Note that: enum X; int a; @X alias g = a; pragma(msg, __traits(getAttributes, g)); prints an empty tuple too because __traits(getAttributes) first resolves the symbol and then checks if any attributes exist in order to accomodate this case: enum X; @X int a; alias g = a; pragma(msg, __traits(getAttributes, g)); prints tuple((X)). In my opinion, the best solution would be to make adding UDAs to aliases illegal and also not allow UDAs to imports as long as imports create aliases behind the scenes. --

https://issues.dlang.org/show_bug.cgi?id=19056 Seb <greensunny12@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |greensunny12@gmail.com --

https://issues.dlang.org/show_bug.cgi?id=19056 Smaulder <smauldersauce@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |smauldersauce@gmail.com --- Comment #2 from Smaulder <smauldersauce@gmail.com> --- > In my opinion, the best solution would be to make adding UDAs to aliases illegal and also not allow UDAs to imports as long as imports create aliases behind the scenes. I disagree, this would cause a lot of breaking changes. It will make it difficult to write code that would otherwise be simple. Attributes are allowed to be applied to aliases even if it does nothing is for simplicity. enum value = 10; struct Foo { @nogc: alias bar = value; // should be an error to allow "@nogc:" // to apply to whole scope for simplicity } Just as some attributes can be applied to symbols that do not do anything: @nogc int variable; // Still allowed, doesn't do anything --

https://issues.dlang.org/show_bug.cgi?id=19056 Andrei Alexandrescu <andrei@erdani.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrei@erdani.com --- Comment #4 from Andrei Alexandrescu <andrei@erdani.com> --- I think named imports and aliases should be entirely transparent, so shouldn't accept attributes (syntactically or semantically). That means fixing this bug entails rejecting the code. Will discuss with Walter. --

July 09, 2018

[Issue 19056] UDAs can be added to imports but not retrieved

Posted by Walter Bright

Permalink

Walter Bright

Permalink

https://issues.dlang.org/show_bug.cgi?id=19056

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com
           Severity|minor                       |enhancement

--- Comment #5 from Walter Bright <bugzilla@digitalmars.com> ---
First off, I agree that aliases should be aliases, not modifications to other symbols. I.e. attributes must not affect the alias. (Changing this behavior will have far reaching consequences in the internal compiler implementation, and would be at risk of a lot of unexpected corner cases.)

As to making:

  @X alias g = a; // (1)

illegal (as opposed to simply ignoring the @X), consider:

  @X { alias g = a; } // (2)
  @Y: alias g = a; // (3)

Making those illegal will cause problems. Then the issue is should (1) be rejected as a special case while ignoring the attributes in (2) and (3)? This behavior isn't the case anywhere else. The three forms are equivalent, it's an easy rule to remember, and easy to have a consistent, correct implementation.

We'd be trading "why don't attributes affect the alias" to "why does the attribute syntax have different behavior w.r.t. aliases"? Is that a net improvement?

Therefore I'm opposed to adding a special case to reject (1). The compiler is working as intended and designed.

(I also changed it to "Enhancement", because the compiler is working as
designed.)

Note that a similar issue has come up recently with:

   int foo(scope int x)

Should 'scope' be an error or be ignored? The answer is ignored, because making it an error would make writing generic code awkward, clumsy, and ugly.

--

https://issues.dlang.org/show_bug.cgi?id=19056 --- Comment #6 from RazvanN <razvan.nitu1305@gmail.com> --- > Making those illegal will cause problems. Then the issue is should (1) be rejected as a special case while ignoring the attributes in (2) and (3)? This behavior isn't the case anywhere else. The three forms are equivalent, it's an easy rule to remember, and easy to have a consistent, correct implementation. final: int a; final {int b;} compile just fine. Whereas: final int a; does not. --

https://issues.dlang.org/show_bug.cgi?id=19056 Iain Buclaw <ibuclaw@gdcproject.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P1 |P3 --

https://issues.dlang.org/show_bug.cgi?id=19056 --- Comment #7 from dlangBugzillaToGithub <robert.schadek@posteo.de> --- THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/17869 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB --

Forums