List of reserved words

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

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';

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

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 //----

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"

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

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

October 11, 2012

Re: List of reserved words

Posted by Alex Rønne Petersen
in reply to Iain Buclaw

Permalink

Alex Rønne Petersen

Posted in reply to Iain Buclaw

Permalink

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 Rønne Petersen
alex@lycus.org
http://lycus.org

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

Forums