Feature request: Attribute with which to enable the requirement of explicit-initialization of enum variables

Diggory diggsey at googlemail.com
Mon Jun 3 09:46:13 PDT 2013


On Monday, 3 June 2013 at 12:13:30 UTC, Maxim Fomin wrote:
> On Monday, 3 June 2013 at 11:12:10 UTC, Diggory wrote:
>> On Monday, 3 June 2013 at 05:56:42 UTC, Maxim Fomin wrote:
>>> On Monday, 3 June 2013 at 02:23:18 UTC, Andrej Mitrovic wrote:
>>>> Let's say you define an enum, which is to be used as a 
>>>> variable:
>>>> ...
>>>>
>>>> Thoughts?
>>>
>>> I think it is simpler to set a first enum member as invalid. 
>>> However, I like an idea of supporting analogue of @disable 
>>> this() mark for any user-defined types, not structs (I mean 
>>> it would be pretty good if such feature applied on classes 
>>> could stop creating null references - it's actually not 
>>> adding new feature, but increasing scope of existing feature).
>>
>> It's completely meaningless on classes: it's already 
>> impossible to create an instance of a class which is null, 
>> because if it's null it's not an instance of the class in the 
>> first place.
>
> This is again using wrong terminology to move meaning from type 
> to pointed data (if any) as happened recently with dynamic 
> arrays. Nothing on the Earth promises that if in one language 
> class type is allocated memory, than in another language class 
> should be also so, and if it is not, then hoards of programmist 
> should use first naming conversion with no reason. Consult the 
> spec what class type is in D and please do not confuse D with 
> other languages.

My point is completely applicable to D - it applies to any form 
of polymorphic type. In D the type of a class variable is 
determined at runtime, not at compile time, so what you're saying 
makes no sense.

The feature you want is exactly what NotNull!T does, the way you 
are suggesting of implementing it doesn't work.


More information about the Digitalmars-d mailing list