www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Proposal: isnot

reply clayasaurus <clayasaurus gmail.com> writes:
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, 


 ?

 It is a small change and easilly done, but once made, we're stuck 

 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?
Mar 05 2005
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
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
Mar 06 2005
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"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. :-(
Mar 06 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Mar 06 2005
prev sibling parent Ben Hinkle <Ben_member pathlink.com> writes:
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
Mar 06 2005