On Mon, 27 May 2013 16:55:54 +0200, deadalnix <[email protected]> wrote:
On Monday, 27 May 2013 at 14:36:26 UTC, Andrei Alexandrescu wrote:
On 5/27/13 5:17 AM, deadalnix wrote:
I'm saying that NonNull require language support, either by making it a
first class entity, or by introducing some other language feature like
@disable this(). At the end it doesn't change anything for the
compiler,
the exact same work have to be done, simply on different entities. It
can't be a 100% library feature as the work around @disable this shows.
The difference is that @disable this() and friends allows implementing
NonNull PLUS a host of other restricted types, whereas plopping NonNull
in the language just stops there. Big difference.
My point being that this is the exact same feature, from a compiler
perspective.
I think that ideally, nonnull pointer should be a core feature.
Considering history, a library solution is preferable.
But the argument about compiler feature don't stand, as nonnull pointer
and @disable this require the exact same processing in the compiler.
No.
See above. Tracking initialization, that's it.
Well, yes. But it does so in a general way, rather than limit it to
non-nullable pointers/references.
If D had added non-nullable references only (no @disable this()), how would
you go about creating a number that's guaranteed to be prime? Would you ask
for that as a separate complier feature?
--
Simen
