KennyTM~ wrote:
> On Dec 7, 09 04:30, Don wrote:
>> KennyTM~ wrote:
>>> On Dec 7, 09 00:23, Andrei Alexandrescu wrote:
>>>> Is there any good use of unary +? As an aside, Perl programs do use it
>>>> occasionally for syntactic disambiguation :o).
>>>>
>>>> Andrei
>>>
>>> Yes, when you want to port the Boost Spirit parser :o) (OK that's an
>>> abuse.)
>>>
>>> Well the unary + can help to emphasize "it's a positive number", and
>>> 1.0e+10 is already a form of "unary +" (not the operator).
>>>
>>> Removing the unary + doesn't lose much, but it doesn't gain much
>>> either, and with it already present in all other languages, I don't
>>> see a good reason to change it.
>>
>> I think + should be added to the syntax for numeric literals, and in all
>> other cases unary + should be dropped.
>> Ie,
>> x = +0.78; should remain legal.
>> But
>> y = +x; should not.
>> And likewise,
>> x = +(+0.78); should be illegal.
>>
>> Overloading + is odd, too. Currently:
>> +x;
>> creates a "has no effect" error if x is a built-in type. But if x has an
>> overloaded unary +, it might have side-effects. So it useful ONLY for
>> operator abuse!
>>
>>
> 
> import std.math;
> 
> auto theta1 = +PI/6;
> auto theta2 = -PI/8;

Good one.

Don wrote:
> Walter Bright wrote:
>> 3. used with operator overloading to convert a user defined type to its preferred arithmetic representation (a cast can't know what the 'preferred' type is)
>  > 5. to coerce default integral promotion rules (again, cast(int) won't
>  > always produce the same result)
> 
> This one is interesting, and might be the strongest argument, but I don't understand it. An example would be interesting.

Integral promotion rules:

byte b;
+b => int

dchar dc;
+dc => uint

long l;
+l => long
cast(int)l => Oops! lost some bits

user defined type:

struct S
{
    long opCast() { ... }
    S opAdd(ref S) { ... }
}

S s;
+s => long result
s + s => S result
s + +s => long result
s + cast(int)s => Oops! lost some bits!

Michiel Helvensteijn wrote:
> Andrei Alexandrescu wrote:
> 
>> Is there any good use of unary +?
> 
> I think it's just good symmetry. It makes a programming language just a
> little bit more elegant. Plus, you keep the 0.01% of programmers that use
> it happy.
> 
> What will removing it gain you?

Sancta simplicitas.

Andrei

Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> Is there any good use of unary +? As an aside, Perl programs do use it occasionally for syntactic disambiguation :o).
> 
> An internet search reveals:
> 
> 1. symmetry
> 
> 2. compatibility with C and many other languages that use it
> 
> 3. used with operator overloading to convert a user defined type to its preferred arithmetic representation (a cast can't know what the 'preferred' type is)
> 
> 4. to create DSL languages, like Spirit, as Kenny points out
> 
> 5. to coerce default integral promotion rules (again, cast(int) won't always produce the same result)
> 
> 6. to visually emphasize that a literal is positive
> 
> I say leave it in.

I am completely underwhelmed by 1-6 and have strong arguments against each, but "frankly, my dear" I have bigger problems than that. I have exactly zero valid reasons I could mention in TDPL, and that's my litmus test. I find the operator utterly useless. If '+' stays in, then call it horsetrading but the occasionally useful '^^=' must also be in.

Andrei

On Dec 7, 09 05:12, Andrei Alexandrescu wrote:
> I am completely underwhelmed by 1-6 and have strong arguments against
> each, but "frankly, my dear" I have bigger problems than that. I have
> exactly zero valid reasons I could mention in TDPL, and that's my litmus
> test. I find the operator utterly useless. If '+' stays in, then call it
> horsetrading but the occasionally useful '^^=' must also be in.
>
> Andrei

There would be zero reason to explain 1.0 vs 1.00, 1.0e2 vs 1.0e+2, and 0xabc vs 0xABC vs 0Xabc vs 0XABC too.

And I thought there isn't ^^= yet just because Don's patch was only a proof-of-concept thing. (Currently 3*4^^2 doesn't event produce the expected result.) ^^= will be in, but that's irrelevant.

Hello bearophile,

> Andrei Alexandrescu:
> 
>> Is there any good use of unary +?
>> 
> In an array of directions I have used -something to mean left and
> +something to mean right, to keep their symmetry. This is an usage,
> but not a good enough one.
> 

I do that sometimes and I'd like to keep doing it, but I'm not shure how improtant that is.

Andrei Alexandrescu wrote:
> Walter Bright wrote:
>> Andrei Alexandrescu wrote:
>>> Is there any good use of unary +? As an aside, Perl programs do use it occasionally for syntactic disambiguation :o).
>>
>> An internet search reveals:
>>
>> 1. symmetry
>>
>> 2. compatibility with C and many other languages that use it
>>
>> 3. used with operator overloading to convert a user defined type to its preferred arithmetic representation (a cast can't know what the 'preferred' type is)
>>
>> 4. to create DSL languages, like Spirit, as Kenny points out
>>
>> 5. to coerce default integral promotion rules (again, cast(int) won't always produce the same result)
>>
>> 6. to visually emphasize that a literal is positive
>>
>> I say leave it in.
> 
> I am completely underwhelmed by 1-6 and have strong arguments against each, but "frankly, my dear" I have bigger problems than that. I have exactly zero valid reasons I could mention in TDPL, and that's my litmus test. I find the operator utterly useless. If '+' stays in, then call it horsetrading but the occasionally useful '^^=' must also be in.

Think of it like the "bool" operator overload. bool gives a direct way for user defined times to be tested for if statements, etc. Similarly, U+ gives a direct way for user defined types to be converted to their most desired arithmetic type.

Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> Walter Bright wrote:
>>> Andrei Alexandrescu wrote:
>>>> Is there any good use of unary +? As an aside, Perl programs do use it occasionally for syntactic disambiguation :o).
>>>
>>> An internet search reveals:
>>>
>>> 1. symmetry
>>>
>>> 2. compatibility with C and many other languages that use it
>>>
>>> 3. used with operator overloading to convert a user defined type to its preferred arithmetic representation (a cast can't know what the 'preferred' type is)
>>>
>>> 4. to create DSL languages, like Spirit, as Kenny points out
>>>
>>> 5. to coerce default integral promotion rules (again, cast(int) won't always produce the same result)
>>>
>>> 6. to visually emphasize that a literal is positive
>>>
>>> I say leave it in.
>>
>> I am completely underwhelmed by 1-6 and have strong arguments against each, but "frankly, my dear" I have bigger problems than that. I have exactly zero valid reasons I could mention in TDPL, and that's my litmus test. I find the operator utterly useless. If '+' stays in, then call it horsetrading but the occasionally useful '^^=' must also be in.
> 
> Think of it like the "bool" operator overload. bool gives a direct way for user defined times to be tested for if statements, etc.

If I think of it that way, that doesn't look too good. The bool operator overload has been an unqualified and admitted failure for C++. The hacks used to avoid that failure are very ingenious; none was within the realm of what the language had planned or intended.

> Similarly, U+ gives a direct way for user defined types to be converted to their most desired arithmetic type.

Code that uses +a to convert a to another type? I'd consider that worse than a hack and worse than incompetent - it's downright malicious.


Andrei

Walter Bright:

> Think of it like the "bool" operator overload. bool gives a direct way for user defined times to be tested for if statements, etc. Similarly, U+ gives a direct way for user defined types to be converted to their most desired arithmetic type.

I'd like opBool in D, for example to implement multiprecision numbers that can be used as integers in:
if (somenumber) {...
Or when I want to give Python-like semantics to my collections, so they can be false when empty (I don't know if this is a good idea, I think it's handy).

I agree with Andrei that type conversions done with + are cryptic, I am not a C expert but I am using it for some time and I have never seen + used that way.

I'd like to keep writing +5.5, with numbers (and maybe with user-defined numbers too).
Unary pos operator overload is available even in Python, it's named __pos__, an answer about it, that shows two bad usages of __pos__:
http://groups.google.com/group/comp.lang.python/msg/07d6fb1e2c7a4f42

This is ugly, I didn't know about this:

>>> import decimal
>>> x = decimal.Decimal("-0.0")
>>> x
Decimal('-0.0')
>>> +x
Decimal('0.0')
>>> x = decimal.Decimal("-2.0")
>>> x
Decimal('-2.0')
>>> +x
Decimal('-2.0')

Keeping opPos allows to write +x where x is a user-defined number (and x must not change sign as in the Python Decimal zero, I don't understand that design decision), so even if it's not so useful I think it's better to keep it in D.

Bye,
bearophile

Andrei Alexandrescu wrote:
> Michiel Helvensteijn wrote:
>> Andrei Alexandrescu wrote:
>>
>>> Is there any good use of unary +?
>>
>> I think it's just good symmetry. It makes a programming language just a little bit more elegant. Plus, you keep the 0.01% of programmers that use it happy.
>>
>> What will removing it gain you?
> 
> Sancta simplicitas.

Removing unary '+' does not simplify the language, but complicates it. In math, '+' and '-' are partners.  Syntactically, in every context where '-' can be used, '+' can also be used.  Keeping this symmetry is the easiest, simplest thing to do.

Yes, it's easy to remember that while '-' works both as a binary and an unary operator, '+' is always binary.  But should one have to?  The omission of unary '+' would be dead weight in the language, reserving a symbol that can never be used for any purpose other than adding unary '+' back in.


-- 
Rainer Deyke - rainerd@eldwood.com