October 11, 2012 Re: List of reserved words | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | 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 Re: List of reserved words | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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 Re: List of reserved words | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarch_dodra | 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 Re: List of reserved words | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarch_dodra | 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 Re: List of reserved words | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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 Re: List of reserved words | ||||
---|---|---|---|---|
| ||||
Posted in reply to Maxim Fomin | 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 Re: List of reserved words | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarch_dodra | 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 Re: List of reserved words | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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 Re: List of reserved words | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarch_dodra | 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 Re: List of reserved words | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarch_dodra | 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 |
Copyright © 1999-2021 by the D Language Foundation