[article] Language Design Deal Breakers
Regan Heath
regan at netmail.co.nz
Wed May 29 06:36:16 PDT 2013
On Wed, 29 May 2013 14:15:07 +0100, deadalnix <deadalnix at gmail.com> wrote:
> On Wednesday, 29 May 2013 at 12:19:54 UTC, Regan Heath wrote:
>>> I started discussing this because people where claiming that non null
>>> makes the compiler more complex to implement, which is completely
>>> false.
>>
>> That's not the argument being made by Simen. The argument is that
>> @disable this() is a feature which allows a set of features which
>> include but is not limited to not-null, and is therefore a superior
>> feature to have.
>>
>> Do you agree?
>>
>
> I do agree that @disable this is useful. *BUT* the argument made is
> based on the untold assumption that both are mutually exclusive, which
> is not true.
I don't believe anyone is arguing that they are mutually exclusive, only
that @disable is sufficient to do the job.
>> IMO, this then renders any specific not-null language feature
>> unnecessary. And, allows a library type to do the job.
>>
>
> Most people agree that you'll find 2 useful behavior : non nullable and
> nullable with obligation of handling the null case. The default behavior
> right now provide none of thoses. It behave just as if it were non
> nullable, and simply crash when they happen to be null.
Which default behaviour? D's references/pointers? Or the proposed
NotNull!(T) library solution?
> This behavior isn't useful. You'll find no argument except historical
> reason (which is a very valid argument BTW) to keep that. Everything
> else is backward rationalization.
If @disable is insufficient for a NotNull!(T) which does what we need it
to do, then more features are required. Ignoring the bugs in @disable, do
you believe it is insufficient? If so, can you give us some example
usages it does not yet support/allow/provide for.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
More information about the Digitalmars-d
mailing list