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.