Make 'is' a prefix operator:

if (is o)
{ ... }

Postfix 'is' would work too:

if (o is)
{ ... }

for the opposite use it infix with null:

if (o is null)
{ ... }

Sean

"Andy Friesen" <andy@ikagames.com> wrote in message news:b6c8am$2c7l$1@digitaldaemon.com...
> Python uses the keyword 'is' where D uses ===. (and 'is not' for !==)
> Maybe this would be better in that it doesn't look similar to == at all.
> (and thus would be a lot harder to confuse)
>
> if (o is not null) ... // more verbose, but totally unambigious.

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:b6bpor$22l9$1@digitaldaemon.com...
>
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b6beok$1qun$1@digitaldaemon.com...
> >
> > Me, I think that if (o) is a heavily established idiom, and if D isn't
> going
> > to support it, it should consider it an error and prepare for the slew
of
> > complaints from people porting C code.
>
> I have to agree, initially I was a bit against if ( o ) and if ( !o ) but
> since I've been doing more C I find I'm writing that in D partly because
> writing  if ( o === null ) is prone to me forgetting the last = and I only
> write == and then get a seggy when o is null.
>

if(x = 0)

should not be allowed in any language. It's not allowed in C# and Java, which have learned from C/C++'s mistake, and in fact most C & C++ compilers these days warn about it. I've never met anyone that suggested that that was a good way to program.

I cannot believe that D _does_ allow it. If it does I may have to go and suck my thumb for a while. That would be too poor. Say it ain't so ... :(

"Matthew Wilson" <dmd@synesis.com.au> wrote in message news:b6d6j8$1qt$1@digitaldaemon.com...
>
> "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:b6bpor$22l9$1@digitaldaemon.com...
> >
> > "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b6beok$1qun$1@digitaldaemon.com...
> > >
> > > Me, I think that if (o) is a heavily established idiom, and if D isn't
> > going
> > > to support it, it should consider it an error and prepare for the slew
> of
> > > complaints from people porting C code.
> >
> > I have to agree, initially I was a bit against if ( o ) and if ( !o )
but
> > since I've been doing more C I find I'm writing that in D partly because writing  if ( o === null ) is prone to me forgetting the last = and I
only
> > write == and then get a seggy when o is null.
> >
>
> if(x = 0)
>
> should not be allowed in any language. It's not allowed in C# and Java, which have learned from C/C++'s mistake, and in fact most C & C++
compilers
> these days warn about it. I've never met anyone that suggested that that
was
> a good way to program.
>
> I cannot believe that D _does_ allow it. If it does I may have to go and suck my thumb for a while. That would be too poor. Say it ain't so ... :(

I think you've missed 2 = 's :)

I end up writing `if ( o == null )`  '=""='
instead of want I wanted which is  `if ( o === null )` '=''=''='

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:b6djff$ab5$1@digitaldaemon.com...
>
> "Matthew Wilson" <dmd@synesis.com.au> wrote in message news:b6d6j8$1qt$1@digitaldaemon.com...
> >
> > "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:b6bpor$22l9$1@digitaldaemon.com...
> > >
> > > "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b6beok$1qun$1@digitaldaemon.com...
> > > >
> > > > Me, I think that if (o) is a heavily established idiom, and if D
isn't
> > > going
> > > > to support it, it should consider it an error and prepare for the
slew
> > of
> > > > complaints from people porting C code.
> > >
> > > I have to agree, initially I was a bit against if ( o ) and if ( !o )
> but
> > > since I've been doing more C I find I'm writing that in D partly
because
> > > writing  if ( o === null ) is prone to me forgetting the last = and I
> only
> > > write == and then get a seggy when o is null.
> > >
> >
> > if(x = 0)
> >
> > should not be allowed in any language. It's not allowed in C# and Java, which have learned from C/C++'s mistake, and in fact most C & C++
> compilers
> > these days warn about it. I've never met anyone that suggested that that
> was
> > a good way to program.
> >
> > I cannot believe that D _does_ allow it. If it does I may have to go and suck my thumb for a while. That would be too poor. Say it ain't so ...
:(
>
> I think you've missed 2 = 's :)
>
> I end up writing `if ( o == null )`  '=""='
> instead of want I wanted which is  `if ( o === null )` '=''=''='
>

Does not compute: what's that got to do with the issue of "if(x = 1)" ?

Notwithstanding that confusion, there is certainly a readability argument against having both == and ===.

If if(x = 0) is illegal, == means compare value and === is replaced with is
(or similar) then there can be no confusion

> Notwithstanding that confusion, there is certainly a readability argument against having both == and ===.

For one, I hate the idea of having them both.
(Or maybe having === alone, hurts me, too.)

I'm sure people will have colorful problems with
them all over the time, especially those migrating
from C/C++.

(I'd prefer something like "is", I guess, instead,
as others also said here and there. What is wrong
with "is"?)

Luna Szabi

On Thu, 3 Apr 2003 18:27:14 +0200, Luna Kid <lunakid@neuropolis.org> wrote:

>> Notwithstanding that confusion, there is certainly a readability argument
>> against having both == and ===.
>
> For one, I hate the idea of having them both.
> (Or maybe having === alone, hurts me, too.)
>
> I'm sure people will have colorful problems with
> them all over the time, especially those migrating
> from C/C++.
>
> (I'd prefer something like "is", I guess, instead,
> as others also said here and there. What is wrong
> with "is"?)

Are you suggesting something like ...

 if (x is y)

then I like the idea. It is then easy to extend it to ...

 if (x is available)

for cases where 'x' is not initialized (or has a value of zero if that's a different thing).

-- 
Derek

"Derek Parnell" <Derek.Parnell@No.Spam> wrote in message news:oprm2xwew0yj5swd@news.digitalmars.com...
> On Thu, 3 Apr 2003 18:27:14 +0200, Luna Kid <lunakid@neuropolis.org>
wrote:
>
> >> Notwithstanding that confusion, there is certainly a readability
> >> argument
> >> against having both == and ===.
> >
> > For one, I hate the idea of having them both.
> > (Or maybe having === alone, hurts me, too.)
> >
> > I'm sure people will have colorful problems with
> > them all over the time, especially those migrating
> > from C/C++.
> >
> > (I'd prefer something like "is", I guess, instead,
> > as others also said here and there. What is wrong
> > with "is"?)
>
> Are you suggesting something like ...
>
>   if (x is y)
>
> then I like the idea. It is then easy to extend it to ...
>
>   if (x is available)
>
> for cases where 'x' is not initialized (or has a value of zero if that's a
> different thing).
>
> --
> Derek


Exactly.

Thanks. :)
Luna Kid

Just to summarize the topic...

> > "Luna Kid" <lunakid@neuropolis.org> wrote in message news:b6aerf$158r$1@digitaldaemon.com...
> > > Mmm... Actuall, I start liking Sean's "with" idea more and more:
> > >
> > >     > with(o)  // skips the whole block if o is null
> > >     > {
> > >     > }

>
[...snip...]
>
> "Matthew Wilson" <dmd@synesis.com.au> wrote in message news:b6aqbd$1ds9$1@digitaldaemon.com...
> > I agree it seems kinda nice, but how to do complex conditional,
involving
> > perhaps a couple of objects, and maybe other conditions?
>
[...snip...]
>
"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b6beok$1qun$1@digitaldaemon.com...
> This would only cover half of the issue.  Assuming one wants distinct
> semantic actions to replace if (o != null) {} and if (o1 == o2), this
would
> only address the former.

Yes, as the core of the idea was separating general-purpose conditionals ("normal if") from checking object availability.

Actually (despite what I said in private to him earlier...),
Sean's with(x) would be _the_ solution.

- As to the syntax, both of the controversial, but frequent
  and practical idioms

    if (x)

  and

    if (x = new object)

  would be supported cleanly.

- As to the semantics: the meaning of the construct could
  be: "if x is initialized, do the following with it".

  What does "initialized" means? That x != null would be fine.

  The current reference semantics allows null values already,
  which does indicate some sort of "uninitializedness" anyway.

  (Just as a side-note: besides the != null choice, it might
  be tempting to say, especially performance-wise, that having

        class_invariant == true

  would also be good, but since "with (x)" is a typical run-
  time success/failure scenario, so, disabling contracts would
  break the program.)

- One "drawback" is the run-time overhead for !=null checking.

  But no program is meaningful, which operates on uninitialized
  references anyway, so the code *must* contain the check, either
  way... Then, it would be the preferable choice that the compiler
  kindly took this routine burden -- and throw some "object
  uninitialized" exception when needed.

- Note, that this same exception could be thrown, when applying
  any other operations on null references, such as ==, see the
  "null == o" thread, for example.

  This also offers a compromise: Walter may say that "with(x)"
  means an _explicit_ object validity check, but ever others
  do only perform no check, or, ideally, verify the class
  invariant in debug mode.

And everyone could be quite OK with this, I think.

Sab

What about conditional

 if (x == y)

where one or both may be null? I assume your with() idea - on which I'm
still cogitating - does not address this issue, which is, in my opinion, a
lot more important than if(x) vs if(x != null)


"Luna Kid" <lunakid@neuropolis.org> wrote in message news:b6q97t$d9f$1@digitaldaemon.com...
> Just to summarize the topic...
>
> > > "Luna Kid" <lunakid@neuropolis.org> wrote in message news:b6aerf$158r$1@digitaldaemon.com...
> > > > Mmm... Actuall, I start liking Sean's "with" idea more and more:
> > > >
> > > >     > with(o)  // skips the whole block if o is null
> > > >     > {
> > > >     > }
>
> >
> [...snip...]
> >
> > "Matthew Wilson" <dmd@synesis.com.au> wrote in message news:b6aqbd$1ds9$1@digitaldaemon.com...
> > > I agree it seems kinda nice, but how to do complex conditional,
> involving
> > > perhaps a couple of objects, and maybe other conditions?
> >
> [...snip...]
> >
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b6beok$1qun$1@digitaldaemon.com...
> > This would only cover half of the issue.  Assuming one wants distinct
> > semantic actions to replace if (o != null) {} and if (o1 == o2), this
> would
> > only address the former.
>
> Yes, as the core of the idea was separating general-purpose conditionals ("normal if") from checking object availability.
>
> Actually (despite what I said in private to him earlier...),
> Sean's with(x) would be _the_ solution.
>
> - As to the syntax, both of the controversial, but frequent
>   and practical idioms
>
>     if (x)
>
>   and
>
>     if (x = new object)
>
>   would be supported cleanly.
>
> - As to the semantics: the meaning of the construct could
>   be: "if x is initialized, do the following with it".
>
>   What does "initialized" means? That x != null would be fine.
>
>   The current reference semantics allows null values already,
>   which does indicate some sort of "uninitializedness" anyway.
>
>   (Just as a side-note: besides the != null choice, it might
>   be tempting to say, especially performance-wise, that having
>
>         class_invariant == true
>
>   would also be good, but since "with (x)" is a typical run-
>   time success/failure scenario, so, disabling contracts would
>   break the program.)
>
> - One "drawback" is the run-time overhead for !=null checking.
>
>   But no program is meaningful, which operates on uninitialized
>   references anyway, so the code *must* contain the check, either
>   way... Then, it would be the preferable choice that the compiler
>   kindly took this routine burden -- and throw some "object
>   uninitialized" exception when needed.
>
> - Note, that this same exception could be thrown, when applying
>   any other operations on null references, such as ==, see the
>   "null == o" thread, for example.
>
>   This also offers a compromise: Walter may say that "with(x)"
>   means an _explicit_ object validity check, but ever others
>   do only perform no check, or, ideally, verify the class
>   invariant in debug mode.
>
> And everyone could be quite OK with this, I think.
>
> Sab
>
>

With respect the the issue of accedentially writing

if( wombat == null ) ...

when the intention is

if( wombat === null ) ...

why not always report value comparason with null as
an error?

id est: `if( wombat == null )` would generate a
compile time error such as `value comparason (==)
with null not allowed, did you mean reference
comparason (===)?`

Such a null value comparason is highly unlikely in
code - I can think of no circumstances where such a
comparason would not be an error (can anyone else?).

This should be possible in only a few lines of
additional code to the compiler, and a line or two
to the documentation.

[Additionally, declaring `if( wombat == null )` as an
error would eliminate the need for checking for null
in the preconditions of the .eq() method.]

C 2003/4/8