On Fri, 10 Jun 2005 09:16:21 +1000, James McComb wrote:

> Derek Parnell wrote:
> 
>> How about a more familiar sort of syntax ...
>> 
>>   ob =? get_object() : new Obj;
> 
> What about this:
> 
> ob ?= get_object() : new Obj;
> 
> ?= by analogy with += *= etc.

Yeah, not bad at all.

-- 
Derek
Melbourne, Australia
10/06/2005 9:18:40 AM

I like that.  The downside is that, in Perl, you can:

print $test || "default";

But you couldn't:

writef(?= $test : "default");

But, of course, I think the ?= usage covers most of the usefulness of such a feature, and fits *much* more nicely with C syntax.

-[Unknown]


> Derek Parnell wrote:
> 
>> How about a more familiar sort of syntax ...
>>   ob =? get_object() : new Obj;
> 
> 
> What about this:
> 
> ob ?= get_object() : new Obj;
> 
> ?= by analogy with += *= etc.
> 
> James McComb

Unknown W. Brackets wrote:

> I like that.  The downside is that, in Perl, you can:
> 
> print $test || "default";
> 
> But you couldn't:
> 
> writef(?= $test : "default");
> 
> But, of course, I think the ?= usage covers most of the usefulness of such a feature, and fits *much* more nicely with C syntax.

It would limit the usefulness if you had to assign the result to a named variable. Looking at how I use || where it has this semantic, it is more often used for temporaries, like funcall(a||b) or as a subexpression.

Would it hurt anything if a||b in D got this functionality? It already has
the semantics a?1:b?1:0 (or is it cast(bit)a?cast(bit)a:cast(bit)b ?)
Changing this to a?a:b would be equivalent in most cases. Apart from dealing
with the implicit cast:

bit x = 0||5;

I can see a potential problem were the operands have different types... ("string"||7)

Another suggestion:  a ?| b

/ Oskar

Hi there,

There're a couple of things I'd like to add:

1) I think most of these proposed syntaxes would work ('!=' or '?|' or '?='). My
preference still lies with the original ('?:') or the Perl-ish variants ('||'
and 'or'), though. Nevertheless, the other suggestions aren't bad at all; I just
don't see any drawback to the original.

2) However, I have to agree with Oskar in that making it necessary to assign the result to a variable limits the usefulness and generally makes things more complicated.

3) Finally, I think a mere extension to an existing type-agnostic (IIRC)
operator (?:) is much simpler and easier to learn as an idiom (or ignored) than
a completely new assignment operator. It also avoids the whole operator
overloading morass. It seems like the path of least resistance; almost nothing
has to change.

Having said that, having any of these would be better than nothing at all. I hope Walter considers some of the options.

Cheers,
--AJG.



In article <d8bf63$jgp$1@digitaldaemon.com>, Oskar Linde says...
>
>Unknown W. Brackets wrote:
>
>> I like that.  The downside is that, in Perl, you can:
>> 
>> print $test || "default";
>> 
>> But you couldn't:
>> 
>> writef(?= $test : "default");
>> 
>> But, of course, I think the ?= usage covers most of the usefulness of such a feature, and fits *much* more nicely with C syntax.
>
>It would limit the usefulness if you had to assign the result to a named variable. Looking at how I use || where it has this semantic, it is more often used for temporaries, like funcall(a||b) or as a subexpression.
>
>Would it hurt anything if a||b in D got this functionality? It already has
>the semantics a?1:b?1:0 (or is it cast(bit)a?cast(bit)a:cast(bit)b ?)
>Changing this to a?a:b would be equivalent in most cases. Apart from dealing
>with the implicit cast:
>
>bit x = 0||5;
>
>I can see a potential problem were the operands have different types... ("string"||7)
>
>Another suggestion:  a ?| b
>
>/ Oskar

I suggest to use ??. Why? Because C# 2.0 does.

# int? x = 42; // nullable type
#
# int foo = x ?? -1;  // foo will be 42
#
#
# int? y = null; // nullable type
#
# int bar = y ?? -1;  // foo will be -1 as y is null