On Wed, 29 May 2013 15:09:11 +0100, deadalnix <[email protected]> wrote:
On Wednesday, 29 May 2013 at 13:36:16 UTC, Regan Heath wrote:
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?
The default behavior. The one you get our of the box. So not NonNullable.
Clearly then NonNullable or @disable is buggy. Isn't this what Walter
meant when he said he was going to patch the holes?
So, assuming the implementation of @disable and NotNullable are fixed to
provide the 2 useful behaviours mentioned above, problem solved right?
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.
I don't know what you answer to, but clearly not what you are quoting.
I quoted it, but inserted my comment above between your 2 paras. You then
stripped it from your reply :P
I have re-quoted it above "Most people agree..".
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
