I'm basically wondering why the __traits keyword looks so horrible.

On Saturday, 2 November 2013 at 20:45:28 UTC, TheFlyingFiddle wrote:
> I'm basically wondering why the __traits keyword looks so horrible.

I think it looks beautiful and wished all the keywords used the leading underscores.

The reason is that the __keywords are reserved, so they don't conflict with user words. __traits was added somewhat late into the language, so using a reserved word for it meant less broken code. Now you can still call your own variables traits - I'd love it if all keywords were this way so we could, in theory at least, use the anywhere.

Anyway, std.traits wraps __traits reasonably well and doesn't have the underscores.

Thanks for the comprehensive answer.

On Saturday, 2 November 2013 at 21:28:46 UTC, Adam D. Ruppe wrote:
> On Saturday, 2 November 2013 at 20:45:28 UTC, TheFlyingFiddle wrote:
>> I'm basically wondering why the __traits keyword looks so horrible.
>
> I think it looks beautiful and wished all the keywords used the leading underscores.
>
> The reason is that the __keywords are reserved, so they don't conflict with user words. __traits was added somewhat late into the language, so using a reserved word for it meant less broken code. Now you can still call your own variables traits - I'd love it if all keywords were this way so we could, in theory at least, use the anywhere.
>
> Anyway, std.traits wraps __traits reasonably well and doesn't have the underscores.

__if (true) {

} __else {

}

__for (...) {

}

__enum {

}

That looks beautiful to you?

On Saturday, 2 November 2013 at 21:28:46 UTC, Adam D. Ruppe wrote:
> On Saturday, 2 November 2013 at 20:45:28 UTC, TheFlyingFiddle wrote:
>> I'm basically wondering why the __traits keyword looks so horrible.
>
> I think it looks beautiful and wished all the keywords used the leading underscores.

This is about taste and it is subjective.

> The reason is that the __keywords are reserved, so they don't conflict with user words. __traits was added somewhat late into the language, so using a reserved word for it meant less broken code. Now you can still call your own variables traits - I'd love it if all keywords were this way so we could, in theory at least, use the anywhere.

Statement that in D __identifiers are reserved is dubious as nothing stops users from defining them (I was under impression that D really prevents but is actually was misconception). D incorporates substantial amount of C but does not impose similar limitations on reserved identifiers (__identifier is not the only one reserved in C). Futhermore, dmd internally generates lots of identifiers and does not prohibit user from 'picking up' them - it is huge amount of accept-invalid code. There is also a bug that code

struct S { void __foo(){} void bar() {} }
pragma(msg, __traits(allMembers, S));

printed only 'bar' since some commit in 2.064 (I haven't tested current version). Except these issues, '__identifiers' and 'identifiers' are pretty much the same. Using the former bears some 'risk' that such identifiers may hijack some symbol but it is low.

I believe that __trais was chosen because of combination of unwillingness to intervene into 'identifiers' category (in some sense it is desire to 'stabilize the language' by pretending that language is 'stable') and belief that introducing new features/fixing existing features should not break existing code (but it is inconsistent policy as the same time pretty much code is broken each release, and there is pretty much another code which will very likely be broken in the future). Anyway, the decision seems to be within the path which was followed by C (_Noreturn, _Thread_local), so it is not that bad.

On Saturday, 2 November 2013 at 22:01:11 UTC, Namespace wrote:
> That looks beautiful to you?

In my ideal world, object.d would alias the __ versions back to the regular ones. (Really, it is int, long, etc. that I'd do like this, just like string. for, if, etc. are fine the way they are.)

The difference between that and the current thing is if the user did define their own thing, it could be disambiguated by the full name.

On Saturday, 2 November 2013 at 22:02:51 UTC, Maxim Fomin wrote:
> Statement that in D __identifiers are reserved is dubious as nothing stops users from defining them

Yeah, but still, you aren't supposed to do it so you can't really complain when it breaks.

On Sat, Nov 02, 2013 at 09:45:26PM +0100, TheFlyingFiddle wrote:
> I'm basically wondering why the __traits keyword looks so horrible.

Because the intention is that users would not use it directly, but via nicer standard library wrappers (e.g. std.traits in Phobos).


T

-- 
I don't trust computers, I've spent too long programming to think that they can get anything right. -- James Miller

On Saturday, 2 November 2013 at 23:01:51 UTC, H. S. Teoh wrote:
> On Sat, Nov 02, 2013 at 09:45:26PM +0100, TheFlyingFiddle wrote:
>> I'm basically wondering why the __traits keyword looks so horrible.
>
> Because the intention is that users would not use it directly, but via
> nicer standard library wrappers (e.g. std.traits in Phobos).
>
>
> T

That makes sence.