On Wednesday, 5 October 2016 at 02:15:13 UTC, Jonathan M Davis wrote:
> The AliasSeq muck is there because for some reason you can't alias the result of __traits, so doing something like
>
> alias sym = __traits(getMember, T, member);
>
> isn't legal. So, this has nothing to do with a recommendation of best practice and everything to do with an annoying bug.
>

When aliasing a single symbol, I find it much cleaner to use...
Identity!(...) or I!(...)
... instead of
AliasSeq!(...)[0]

On Wednesday, 5 October 2016 at 02:15:13 UTC, Jonathan M Davis wrote:
> On Wednesday, October 05, 2016 11:20:44 Manu via Digitalmars-d wrote:
>> > While you're at it, might I suggest also adding std.traits.isProperty?
>> >
>> >  Something like:
>> > template isProperty(T, string member)
>> > {
>> >
>> >   import std.meta : AliasSeq;
>> >   import std.traits : FunctionTypeOf;
>> >   alias sym = AliasSeq!(__traits(getMember, T, member))[0];
>> >   enum isProperty = !is(typeof(sym) == function) &&
>> >
>> > is(FunctionTypeOf!(typeof(&sym)) == function);
>> > }
>>
>> Why this AliasSeq business? That line is rather an abomination... why are all these horrible expressions popping up as recommendations nowadays?
>
> The AliasSeq muck is there because for some reason you can't alias the result of __traits, so doing something like
>
> alias sym = __traits(getMember, T, member);
>
> isn't legal. So, this has nothing to do with a recommendation of best practice and everything to do with an annoying bug.
>
> https://issues.dlang.org/show_bug.cgi?id=7804
>
> It _is_ however recommended to use __traits(getMember, T, member) over manually building it with strings with something like T.stringof ~ "." ~ member, because the string manipulation falls about in corner cases (e.g. it could result in a symbol conflict). It's just that then has the unfortunate side effect of requiring AliasSeq because of the bug.
>
> - Jonathan M Davis

https://dlang.org/phobos/std_meta.html#.Alias   :)

On Wednesday, October 05, 2016 09:24:56 John Colvin via Digitalmars-d wrote:
> > It _is_ however recommended to use __traits(getMember, T, member) over manually building it with strings with something like T.stringof ~ "." ~ member, because the string manipulation falls about in corner cases (e.g. it could result in a symbol conflict). It's just that then has the unfortunate side effect of requiring AliasSeq because of the bug.
> >
> > - Jonathan M Davis
>
> https://dlang.org/phobos/std_meta.html#.Alias   :)

IMHO, that doesn't improve things much, but it is slightly shorter. Thanks for pointing it out.

- Jonathan M Davis

On 5 October 2016 at 19:45, Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, October 05, 2016 09:24:56 John Colvin via Digitalmars-d wrote:
>> > It _is_ however recommended to use __traits(getMember, T, member) over manually building it with strings with something like T.stringof ~ "." ~ member, because the string manipulation falls about in corner cases (e.g. it could result in a symbol conflict). It's just that then has the unfortunate side effect of requiring AliasSeq because of the bug.
>> >
>> > - Jonathan M Davis
>>
>> https://dlang.org/phobos/std_meta.html#.Alias   :)
>
> IMHO, that doesn't improve things much, but it is slightly shorter. Thanks for pointing it out.

I thought there was a distinction between typetuple and alias? Some
expression can be captured by a typetuple, but not by alias?
There must be a reason for that horrible and prolific pattern "(T...)
if(T.length == 1) { ... T[0] ... }" instead of "(alias T) { ... T ...
}"?

On Thursday, October 06, 2016 00:38:54 Manu via Digitalmars-d wrote:
> I thought there was a distinction between typetuple and alias? Some
> expression can be captured by a typetuple, but not by alias?
> There must be a reason for that horrible and prolific pattern "(T...)
> if(T.length == 1) { ... T[0] ... }" instead of "(alias T) { ... T ...
> }"?

That has to do with the fact alias template parameters don't take keywords, even if they're types. alias declarations don't have that problem. If they did, we couldn't have stuff like size_t or c_long. In theory, Walter has agreed that we'll fix it so that template alias parameters are consistent with alias declarations, but that hasn't happened yet. And until it does, we're stuck with the weird variadic templates of length 1.

- Jonathan M Davis

On 6 October 2016 at 01:07, Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Thursday, October 06, 2016 00:38:54 Manu via Digitalmars-d wrote:
>> I thought there was a distinction between typetuple and alias? Some
>> expression can be captured by a typetuple, but not by alias?
>> There must be a reason for that horrible and prolific pattern "(T...)
>> if(T.length == 1) { ... T[0] ... }" instead of "(alias T) { ... T ...
>> }"?
>
> That has to do with the fact alias template parameters don't take keywords, even if they're types. alias declarations don't have that problem. If they did, we couldn't have stuff like size_t or c_long. In theory, Walter has agreed that we'll fix it so that template alias parameters are consistent with alias declarations, but that hasn't happened yet. And until it does, we're stuck with the weird variadic templates of length 1.

I see. It sounds like one of these things that needs a serious priority boost.
There are a lot of weirdness-es in template code that make is SO HARD
for non-absolute-experts to understand. It's practically impossible to
author correct code unless you are a serious forum regular of a phobos
contributor.
These weird patterns that are effectively workarounds need to be
ejected into space as soon as possible. I get seriously embarrassed
every time I have to explain these sorts of things to one my
colleagues!