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

[Diggory]

On Monday, 3 June 2013 at 17:36:13 UTC, Maxim Fomin wrote:
> On Monday, 3 June 2013 at 16:46:15 UTC, Diggory wrote:
>> 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.
>
> No, this is completely wrong. D has static type system and type 
> of expression is determined at compile time.

No that's wrong, the static type only determines the highest 
class in the class hierarchy that can be stored, it does not 
determine the actual runtime type of the expression.

If you try to implement "@disable this" using the static type it 
breaks all the rules of covariance and contravariance that 
classes are expected to follow, and thus breaks the type system. 
That's why it's implemented as NotNull!T.