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

bitter.taste@gmx.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bitter.taste@gmx.com

--- Comment #1 from bitter.taste@gmx.com ---
Covered by DMD's PR https://github.com/dlang/dmd/pull/6476

--

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

Mathias Lang <mathias.lang@sociomantic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mathias.lang@sociomantic.co
                   |                            |m

--- Comment #2 from Mathias Lang <mathias.lang@sociomantic.com> ---
I would point to the spec here: http://dlang.org/spec/declaration.html#AliasDeclaration

> `AliasDeclarations` create a symbol that is an alias for another type, and can be used anywhere that other type may appear.

> Aliased types are semantically identical to the types they are aliased to. The debugger cannot distinguish between them, and there is no difference as far as function overloading is concerned.

To me, it sounds like you are looking to create a subtype, in which case `Typedef` would be a better approach. `alias` is just not designed for this. This really sounds like a DIP to me.

--

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

--- Comment #3 from Mike Parker <aldacron@gmail.com> ---
Not at all. allMembers returns FuncPtr and funcPtr as distinct symbols. What I'm looking for is a generic way to know that one is an alias declaration and the other is not.

--

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

--- Comment #4 from Mike Parker <aldacron@gmail.com> ---
(In reply to Mike Parker from comment #3)
> Not at all. allMembers returns FuncPtr and funcPtr as distinct symbols. What I'm looking for is a generic way to know that one is an alias declaration and the other is not.

And to be clear, I'm talking about at compile time. I realize it's not possible at runtime, but surely the compiler knows the difference.

--

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

b2.temp@gmx.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |b2.temp@gmx.com

--- Comment #5 from b2.temp@gmx.com ---
(In reply to Mike Parker from comment #4)
> (In reply to Mike Parker from comment #3)
> > Not at all. allMembers returns FuncPtr and funcPtr as distinct symbols. What I'm looking for is a generic way to know that one is an alias declaration and the other is not.
> 
> And to be clear, I'm talking about at compile time. I realize it's not possible at runtime, but surely the compiler knows the difference.

Imagine a text-based serializer (like JSON, in opposite to a binary serializer)
- The serializer writes a size_t under a x86_64 OS and send it over the network
- An x86 machine reads it in a size_t
=> overflow...

In this case I wish to use __traits(isAlias) in a template constraint or in a static assert to reject the value (e.g "cannot write an aliased type"). The serializer, without type info, really doesn't want any platform specific type.

To get the info at CT or at RT doesn't make any difference. Any custom type info structure would use __traits(isAlias) to generate a static instance for an aggregate field of whatever.

--

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

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #6 from Walter Bright <bugzilla@digitalmars.com> ---
I see this is a feature that could lead to a lot of unforeseen consequences. The language semantics very much rely on an alias being indistinguishable from the target.

As for the size_t example, it's not even possible to serialize it as a size_t. It will go out as int or long. Name mangle a size_t, and there is no size_t mangling, it's int or long.

> __traits(getAllMembers, funcs)

Perhaps a better solution is to have getAllMembers ignore aliases, as aliases are members only for the purpose of symbol lookup.

--

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

--- Comment #7 from Mike Parker <aldacron@gmail.com> ---
(In reply to Walter Bright from comment #6)
> 
> > __traits(getAllMembers, funcs)
> 
> Perhaps a better solution is to have getAllMembers ignore aliases, as aliases are members only for the purpose of symbol lookup.

That's fine, too. Anything that allows filtering out the aliases from the actual symbols during reflection to avoid redundancy.

--

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

--- Comment #8 from Basile-z <b2.temp@gmx.com> ---
another very typical case where the fact that allMembers trait doesn't filter out aliases is when using an alias to deprecate the name of a symbol.

---
//library...
enum Iter;

struct Foo
{
    @Iter Object[] items;
    /// will be removed on 01-01-2021
    deprecated alias elements = items;
}

//app...
void main()
{
    import std.traits;
    alias Iterable = getSymbolsByUDA!(Foo, Iter);
}
---

--

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

Basile-z <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|b2.temp@gmx.com             |

--

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

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--