[article] Language Design Deal Breakers

[Jonathan M Davis]

On Monday, May 27, 2013 11:17:57 deadalnix wrote:
> On Monday, 27 May 2013 at 09:08:16 UTC, Walter Bright wrote:
> > On 5/27/2013 2:05 AM, deadalnix wrote:
> >> On Monday, 27 May 2013 at 08:06:48 UTC, Jonathan M Davis wrote:
> >>>> That is not enough. NotNull must be initialized, so the
> >>>> compiler
> >>>> have to track initialization in way it don't do today. This
> >>>> is
> >>>> the exact same processing required to ensure non null
> >>>> references.
> >>> 
> >>> @disable this(); would solve that.
> >> 
> >> That is the point, the logic required to support @disable this
> >> is the exact same
> >> that the one required to support non null. That is the
> >> freaking same thing :
> >> track initialization and yell at the programmer when you can't
> >> find it.
> > 
> > Are you arguing that notnull should be a core language feature
> > instead of a library one?
> 
> 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.
> 
> 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.

Except that we already have that feature and have had it for some time. It's 
just that it has bugs which need to be sorted out (at least some of which were 
recently fixed). So, we don't need any features for NotNull to work that 
weren't going to have anyway.

- Jonathan M Davis