October 11, 2012
On Thursday, October 11, 2012 10:46:03 Ali Çehreli wrote:
> On 10/11/2012 10:13 AM, Jonathan M Davis wrote:
> > (arguably no one should really be using hash_t or equals_t at this
> 
> point, but
> 
> > I don't know if they're ever going to actually go away).
> 
> I've been assuming that they were relatively newer aliases. Is it recommended to use size_t and bool instead?

They're old. equals_t was done because D1 uses (used?) int for opEquals instead of bool. I don't know if there was ever a good reason for hash_t to exist. I don't believe that TDPL uses either, and I believe that they've been mostly removed from druntime and Phobos (if they haven't been entirely removed yet, they will be, aside from the aliases themselves).

So, I would definitely recommend not using equals_t or hash_t, but while some of us are definitely looking to get rid of them entirely, I suspect that they'll be around semi-permanently just to preserve backwards compatibility.

- Jonathan M Davis
October 11, 2012
On Thursday, 11 October 2012 at 17:57:01 UTC, Jonathan M Davis
wrote:
> On Thursday, October 11, 2012 10:46:03 Ali Çehreli wrote:
>> On 10/11/2012 10:13 AM, Jonathan M Davis wrote:
>> > (arguably no one should really be using hash_t or equals_t at this
>> 
>> point, but
>> 
>> > I don't know if they're ever going to actually go away).
>> 
>> I've been assuming that they were relatively newer aliases. Is it
>> recommended to use size_t and bool instead?
>
> They're old. equals_t was done because D1 uses (used?) int for opEquals
> instead of bool. I don't know if there was ever a good reason for hash_t to
> exist. I don't believe that TDPL uses either, and I believe that they've been
> mostly removed from druntime and Phobos (if they haven't been entirely removed
> yet, they will be, aside from the aliases themselves).
>
> So, I would definitely recommend not using equals_t or hash_t, but while some
> of us are definitely looking to get rid of them entirely, I suspect that
> they'll be around semi-permanently just to preserve backwards compatibility.
>
> - Jonathan M Davis

In C, *technically*, anything ending in _t is reserved for future
usage, but this is not enforced.

Does D also reserve those names? Shouldn't it?
October 11, 2012
On Thursday, October 11, 2012 20:20:26 monarch_dodra wrote:
> In C, *technically*, anything ending in _t is reserved for future usage, but this is not enforced.
> 
> Does D also reserve those names? Shouldn't it?

We have no so such policy AFAIK, but it's not exactly considered good style to use them either - particularly since normally, user-defined types use PascalCase, and pretty much everything else uses camelCase. name_t isn't even really a valid name (though some people would probably still use that sort of name - not everyone sticks to the typical D naming style).

Typically, we only use _t names for stuff that's related to C or which is a variable sized type, in which case we swiped the C name for it (e.g. size_t). equals_t and hash_t are a bit of an exception to that, so they're quite of odd regardless.

In any case though, regardless of whether *_t are considered reserved in any way shape or form, that doesn't mean that we'd want to keep equals_t or hash_t around long term, let alone use them. And we're not likely to use them for anything new unless we're just aliasing more stuff from C for C bindings, but that kind of stuff would probably end up in the druntime C bindings and not object.di where it would affect everything.

- Jonathan M Davis
October 11, 2012
On Thursday, 11 October 2012 at 18:20:27 UTC, monarch_dodra wrote:
> In C, *technically*, anything ending in _t is reserved for future
> usage, but this is not enforced.

Where this is claimed?


October 11, 2012
On Thursday, 11 October 2012 at 07:00:10 UTC, Jacob Carlborg wrote:
> On dlang.org there's a page containing all the keywords, which are reserved:
>
> http://dlang.org/lex.html
>
> But it would also be nice to have a list of words/symbols that are not keywords but could otherwise be thought of being reserved. These are words that will make it problematic if used in user code in the wrong context. I thinking mostly of naming a module "object" or a class "Object", the compiler will not be happy seeing that.
>
> What other "reserved" words like these does D have?

http://dpaste.dzfl.pl/c67b25a9

_param_%x identifiers where %x is an integer from 0 are implicitly declared and correspond to anonymous function parameters.


October 11, 2012
On 11-10-2012 20:41, Maxim Fomin wrote:
> On Thursday, 11 October 2012 at 18:20:27 UTC, monarch_dodra wrote:
>> In C, *technically*, anything ending in _t is reserved for future
>> usage, but this is not enforced.
>
> Where this is claimed?
>
>

6.10.7.2:

None of these macro names, nor the identifier defined, shall be the subject of a  #define or a #undef preprocessing directive. Any other predefined macro names  shall begin with a leading underscore followed by an uppercase letter or a second  underscore.

So, it's not explicitly reserved, but your code can suddenly start doing weird things if you prefix an identifier with an underscore.

This is why new keywords/types are named like _Noreturn, _Thread_local, etc.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
October 11, 2012
On 11-10-2012 20:20, monarch_dodra wrote:
> On Thursday, 11 October 2012 at 17:57:01 UTC, Jonathan M Davis
> wrote:
>> On Thursday, October 11, 2012 10:46:03 Ali Çehreli wrote:
>>> On 10/11/2012 10:13 AM, Jonathan M Davis wrote:
>>> > (arguably no one should really be using hash_t or equals_t > at this
>>>
>>> point, but
>>>
>>> > I don't know if they're ever going to actually go away).
>>>
>>> I've been assuming that they were relatively newer aliases. Is it
>>> recommended to use size_t and bool instead?
>>
>> They're old. equals_t was done because D1 uses (used?) int for opEquals
>> instead of bool. I don't know if there was ever a good reason for
>> hash_t to
>> exist. I don't believe that TDPL uses either, and I believe that
>> they've been
>> mostly removed from druntime and Phobos (if they haven't been entirely
>> removed
>> yet, they will be, aside from the aliases themselves).
>>
>> So, I would definitely recommend not using equals_t or hash_t, but
>> while some
>> of us are definitely looking to get rid of them entirely, I suspect that
>> they'll be around semi-permanently just to preserve backwards
>> compatibility.
>>
>> - Jonathan M Davis
>
> In C, *technically*, anything ending in _t is reserved for future
> usage, but this is not enforced.
>
> Does D also reserve those names? Shouldn't it?

In D, any identifier starting with two underscores is reserved for implementation-specific keywords/other magic.

http://dlang.org/lex.html#IdentifierStart

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
October 11, 2012
On 10/11/2012 11:52 AM, Alex Rønne Petersen wrote:
> On 11-10-2012 20:41, Maxim Fomin wrote:
>> On Thursday, 11 October 2012 at 18:20:27 UTC, monarch_dodra wrote:
>>> In C, *technically*, anything ending in _t is reserved for future
>>> usage, but this is not enforced.
>>
>> Where this is claimed?
>>
>>
>
> 6.10.7.2:
>
> None of these macro names, nor the identifier defined, shall be the
> subject of a #define or a #undef preprocessing directive. Any other
> predefined macro names shall begin with a leading underscore followed by
> an uppercase letter or a second underscore.
>
> So, it's not explicitly reserved, but your code can suddenly start doing
> weird things if you prefix an identifier with an underscore.
>
> This is why new keywords/types are named like _Noreturn, _Thread_local,
> etc.
>

I am sure Maxim knows about the "leading underscore" case. I think that's why "anything ending in _t" is being questioned. :)

I would like to know that too. I have never heard that names ending with _t are reserved in C or C++.

Ali
October 11, 2012
On 2012-10-11 14:44, monarch_dodra wrote:

> Never mind, "Identifiers starting with __ (two underscores) are reserved"

It's not enforced by the compiler.

-- 
/Jacob Carlborg
October 11, 2012
On 2012-10-11 14:43, monarch_dodra wrote:

> __ctfe
>
> Although I should file that as a bug I guess:
>
> //----
> void main()
> {
>      bool __ctfe = true;
> }
> //----
> Internal error: ..\ztc\cgcs.c 522
> //----

An internal error or assert in the compiler is always a bug.

-- 
/Jacob Carlborg