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.
