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

[Maxim Fomin]

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.

Anyway, this irrelevant here, because what I mean is:

class A
{
	@disable this(); // or @RequireInit
}

A a; // does not work

Currently @disable prevents allocation with specified ctor, but 
does not stops from creating null initialized object. Giving 
demand for non-nullable classes, probably it is a good idea to 
support this feature by broading @disable this in context of 
classes or creating similar feature from scrath like 
@RequireInit. This issue with classes is more important than with 
enums, and if such feature is implemented, I see no reason for it 
not to work with enums as with other user-defined types. And if 
consensus is that the feature in classes is not need, then it is 
likely less needed in enums.