www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - List of reserved words

reply Jacob Carlborg <doob me.com> writes:
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?

-- 
/Jacob Carlborg
Oct 10 2012
next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 11 October 2012 07:36, Jacob Carlborg <doob me.com> 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?

 --
 /Jacob Carlborg

Pick your list from object.d: Object Throwable Exception Error ClassInfo ModuleInfo TypeInfo TypeInfo_Class TypeInfo_Interface TypeInfo_Struct TypeInfo_Typedef TypeInfo_Pointer TypeInfo_Array TypeInfo_AssociativeArray TypeInfo_Enum TypeInfo_Function TypeInfo_Delegate TypeInfo_Tuple TypeInfo_Const TypeInfo_Invariant TypeInfo_Shared TypeInfo_Wild TypeInfo_Vector -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 11 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-11 13:00, Iain Buclaw wrote:

 Pick your list from object.d:

 Object
 Throwable
 Exception
 Error
 ClassInfo
 ModuleInfo
 TypeInfo
 TypeInfo_Class
 TypeInfo_Interface
 TypeInfo_Struct
 TypeInfo_Typedef
 TypeInfo_Pointer
 TypeInfo_Array
 TypeInfo_AssociativeArray
 TypeInfo_Enum
 TypeInfo_Function
 TypeInfo_Delegate
 TypeInfo_Tuple
 TypeInfo_Const
 TypeInfo_Invariant
 TypeInfo_Shared
 TypeInfo_Wild
 TypeInfo_Vector

Right, any others hiding somewhere else? -- /Jacob Carlborg
Oct 11 2012
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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 

 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? Ali
Oct 11 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
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
Oct 11 2012
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Oct 11 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 11-10-2012 20:55, Ali Çehreli wrote:
 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

Aaah, my bad. I somehow completely missed the _t. Disregard me! -- Alex Rønne Petersen alex lycus.org http://lycus.org
Oct 11 2012
prev sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
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
Oct 11 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
Oct 11 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Oct 11 2012
prev sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 11-10-2012 13:00, Iain Buclaw wrote:
 On 11 October 2012 07:36, Jacob Carlborg <doob me.com> 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?

 --
 /Jacob Carlborg

Pick your list from object.d: Object Throwable Exception Error ClassInfo ModuleInfo TypeInfo TypeInfo_Class TypeInfo_Interface TypeInfo_Struct TypeInfo_Typedef TypeInfo_Pointer TypeInfo_Array TypeInfo_AssociativeArray TypeInfo_Enum TypeInfo_Function TypeInfo_Delegate TypeInfo_Tuple TypeInfo_Const TypeInfo_Invariant TypeInfo_Shared TypeInfo_Wild TypeInfo_Vector

It's Classinfo by the way (for whatever reason...). Some more: AssociativeArray OffsetTypeInfo MemberInfo MemberInfo_field MemberInfo_function _dg_t _dg2_t Functions: opEquals (there's a global function) setSameMutex _aaLen _aaGet _aaGetRvalue _aaIn _aaDel _aaValues _aaKeys _aaRehash _aaApply _aaApply2 _d_assocarrayliteralT destroy clear capacity reserve assumeSafeAppend _ArrayEq _xopEquals __ctfeWrite __ctfeWriteln Templates: _isStaticArray RTInfo I think that's about it. -- Alex Rnne Petersen alex lycus.org http://lycus.org
Oct 11 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-11 19:21, Alex Rnne Petersen wrote:

 It's Classinfo by the way (for whatever reason...).

 Some more:

 AssociativeArray
 OffsetTypeInfo
 MemberInfo
 MemberInfo_field
 MemberInfo_function
 _dg_t
 _dg2_t

 Functions:

 opEquals (there's a global function)
 setSameMutex
 _aaLen
 _aaGet
 _aaGetRvalue
 _aaIn
 _aaDel
 _aaValues
 _aaKeys
 _aaRehash
 _aaApply
 _aaApply2
 _d_assocarrayliteralT
 destroy
 clear
 capacity
 reserve
 assumeSafeAppend
 _ArrayEq
 _xopEquals
 __ctfeWrite
 __ctfeWriteln

 Templates:

 _isStaticArray
 RTInfo

 I think that's about it.

This list starts to get fairly long. Would there be a point of adding this to dlang.org, somewhere? -- /Jacob Carlborg
Oct 11 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-10-11 21:28, Jonathan M Davis wrote:

 A lot of it is there already: http://dlang.org/phobos/object.html

I wouldn't count that list. I'm thinking more something that explicitly says: "These are reserved symbols by the language or the runtime". Creating your own function named "assumeSafeAppend" actually works fine. On the other hand, naming a module "object" is known to cause Bad Things to happen. So there are some differences. -- /Jacob Carlborg
Oct 11 2012
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, October 11, 2012 21:00:58 Jacob Carlborg wrote:
 This list starts to get fairly long. Would there be a point of adding
 this to dlang.org, somewhere?

A lot of it is there already: http://dlang.org/phobos/object.html - Jonathan M Davis
Oct 11 2012
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 11 October 2012 at 11:44:36 UTC, Jacob Carlborg 
wrote:
 On 2012-10-11 13:00, Iain Buclaw wrote:


 Right, any others hiding somewhere else?

__ctfe Although I should file that as a bug I guess: //---- void main() { bool __ctfe = true; } //---- Internal error: ..\ztc\cgcs.c 522 //----
Oct 11 2012
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 11 October 2012 at 13:07:28 UTC, monarch_dodra wrote:
 On Thursday, 11 October 2012 at 11:44:36 UTC, Jacob Carlborg 
 wrote:
 On 2012-10-11 13:00, Iain Buclaw wrote:


 Right, any others hiding somewhere else?

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

Never mind, "Identifiers starting with __ (two underscores) are reserved"
Oct 11 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2012-10-11, 14:44, monarch_dodra wrote:

 On Thursday, 11 October 2012 at 13:07:28 UTC, monarch_dodra wrote:
 On Thursday, 11 October 2012 at 11:44:36 UTC, Jacob Carlborg wrote:
 On 2012-10-11 13:00, Iain Buclaw wrote:


 Right, any others hiding somewhere else?

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

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

Still, it shouldn't exactly crash the compiler. -- Simen
Oct 11 2012
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 11 October 2012 at 13:27:05 UTC, Simen Kjaeraas 
wrote:
 Still, it shouldn't exactly crash the compiler.

http://d.puremagic.com/issues/show_bug.cgi?id=8801
Oct 11 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, October 11, 2012 13:20:28 Jacob Carlborg wrote:
 On 2012-10-11 13:00, Iain Buclaw wrote:
 Pick your list from object.d:
 
 Object
 Throwable
 Exception
 Error
 ClassInfo
 ModuleInfo
 TypeInfo
 TypeInfo_Class
 TypeInfo_Interface
 TypeInfo_Struct
 TypeInfo_Typedef
 TypeInfo_Pointer
 TypeInfo_Array
 TypeInfo_AssociativeArray
 TypeInfo_Enum
 TypeInfo_Function
 TypeInfo_Delegate
 TypeInfo_Tuple
 TypeInfo_Const
 TypeInfo_Invariant
 TypeInfo_Shared
 TypeInfo_Wild
 TypeInfo_Vector

Right, any others hiding somewhere else?

Also in object.di but not listed by Iain: size_t, ptrdiff_t, sizediff_t, string, wstirng, dstring, hash_t, and equals_t (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). But I think that it's basically a matter of what the actual keywords are and what's listed in object.di, because everything implicitly imports object.di. I don't think that there's anything outside of that that you have to worry about. - Jonathan M Davis
Oct 11 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Oct 11 2012
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
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?
Oct 11 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Oct 11 2012
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
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?
Oct 11 2012
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
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.
Oct 11 2012
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 11 October 2012 at 18:41:14 UTC, 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?

I seem to have been... "inaccurate" in my claim. This is actually a POSIX restriction, not an ISO C one. http://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html
Oct 11 2012
prev sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
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?

From druntime: one underscore + lower letter: http://pastebin.com/iztLZh4m. I guess parsing for double underscores and one underscore + upper letter is meaningless, since defining such identifiers is looking for problems anyway.
Oct 11 2012