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 "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
next sibling parent reply "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
next sibling parent reply "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
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 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 "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
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 


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?

Ali
Oct 11 2012
parent reply "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
parent reply "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
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 reply "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
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 "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 =?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 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
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 reply 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
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 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 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