Thread overview
Re: Proposal: isnot
Mar 06, 2005
clayasaurus
Mar 06, 2005
Matthew
Mar 06, 2005
Ben Hinkle
March 06, 2005
Walter wrote:
> "Achilleas Margaritis" <axilmar@b-online.gr> wrote in message
> news:c7lb26$1skj$1@digitaldaemon.com...
>
>>I am currently writing some GUI application with D, and I found it is
>>tiresome and errorprone to write !(foo is null) all the time. I think D
>>would benefit from an 'isnot' operator. If it existed, I could write 'foo
>>isnot null' and be more productive, since it is easy to forget the ! and
>>makes the code more beautiful since less parentheses are needed.
>>
>>It is a small change, easily done in my opinion. What do you think, Walter
>
> ?
>
> It is a small change and easilly done, but once made, we're stuck with it.
> I'd like to run with the current scheme for a while longer first.
>

Just curious, how much while longer are you thinking? pre or post 1.0? will there be some kind of poll on which 'is not' operator is the best for D?
March 06, 2005
clayasaurus wrote:

> will there be some kind of poll on which 'is not' operator is the best for D?

You mean like:
a) foo !== null
b) foo
c) !(foo is null)
d) foo isnot null
e) foo ~is null
f) foo ≢ null
g) foo || die
h) foo ain't nuthin'

I thought this issue was all settled, in favor of the terse option b):

> assert(foo);

--anders
March 06, 2005
"Anders F Björklund" <afb@algonet.se> wrote in message news:d0edhj$2f76$1@digitaldaemon.com...
> clayasaurus wrote:
>
>> will there be some kind of poll on which 'is not' operator is the best for D?
>
> You mean like:
> a) foo !== null
> b) foo
> c) !(foo is null)
> d) foo isnot null
> e) foo ~is null
> f) foo ? null
> g) foo || die
> h) foo ain't nuthin'
>
> I thought this issue was all settled, in favor of the terse option b):
>
>> assert(foo);
>
> --anders

I don't recall it being settled. I doubt it'll change, but you're never going to see any of my code with implicit boolean sub-expressions.

:-(



March 06, 2005
Matthew wrote:

>>I thought this issue was all settled, in favor of the terse option b):
>>
>>>assert(foo);
> 
> I don't recall it being settled. I doubt it'll change, but you're never
> going  to see any of my code with implicit boolean sub-expressions.
> 
> :-(

I think the (now deprecated?) version that Mango uses is the best:
assert(foo !== null);

It's a little dangerous, since you can easily mix it up with '!='...
(especially if coming from e.g. Java, and being used to that form ?)

But I find the "supported" way of writing to be too long and inverse:
assert(!(foo is null));


However, it doesn't seem like D will ever get 'boolean' (nor 'String')
Fortunately we can still use "bool" and the "long forms", and pretend...

bool a = true;
bool b = integer != 0;
bool c = pointer != null;

Some D parts assumes the "short forms", though, like "in" and "cast".

These expressions tend to look somewhat cumbersome:
if (!((key in hash) is null)) { ... } // AA lookup
if (!((cast(C) obj) is null)) { ... } // instanceof

Compared to the D forms possible, without booleans:
if (key in hash) { ... }
if (cast(C) obj) { ... }

But I rather have the old-fashioned limonade, than sulk over lemons?
Which in the end probably means writing C-style conditionals, to me.

--anders
March 06, 2005
In article <d0edhj$2f76$1@digitaldaemon.com>, =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= says...
>
>clayasaurus wrote:
>
>> will there be some kind of poll on which 'is not' operator is the best for D?
>
>You mean like:
>a) foo !== null
>b) foo
>c) !(foo is null)
>d) foo isnot null
>e) foo ~is null
>f) foo ≢ null
>g) foo || die
>h) foo ain't nuthin'
>
>I thought this issue was all settled, in favor of the terse option b):
>
>> assert(foo);
>
>--anders

FWIW in my code I use x !== y instead of !(x is y). I think it is easier on my tired little brain to process !== over first processing "is" and then the !. I do use "is" instead of ===, though since === is too many equal signs in a row and it looks kinda ugly. Plus "is" has one fewer character.

-Ben