December 07, 2009
Andrei Alexandrescu Wrote:

> > What will removing it gain you?
> 
> Sancta simplicitas.

Hm.. I don't really buy that argument.

I see you and Walter removing/witholding things (incomparability operators, logical operator overloading) from the language, because: "I can't imagine a use for it and removing it makes the language simpler."

Meanwhile, you're keeping C syntax for function-pointers around, and I'm missing syntactic sugar for my tribool.

The fact that you or I think there isn't a use for a feature, doesn't mean there isn't one. Programmers keep finding new and unintended uses for language features, which is a good thing. And if you want to simplify the language, I wouldn't start with the unary + when you've still got all that C stuff around.

-- 
Michiel Helvensteijn

December 07, 2009
Denis Koroskin wrote:

> On Mon, 07 Dec 2009 10:36:16 +0300, Johan Granberg <lijat.meREM@ovegmail.com> wrote:
> 
>> Andrei Alexandrescu wrote:
>>
>>> Brad Roberts wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> bearophile wrote:
>>>>>> 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) {...
>>>>> Unfortunately experience with C++ has shown that things look simpler
>>>>> than they are. If opBool is an implicit conversion to bool, then all
>>>>> sorts of weird expressions are allowed. That's why conversion to bool
>>>>> is
>>>>> flat out unrecommended in C++. Instead, various libraries found
>>>>> alternate ways to allow testing with if without compromising things
>>>>> too
>>>>> much. Loki uses conversion to an opaque pointer type. Boost uses
>>>>> conversion to a pointer to member. The standard itself uses, I think,
>>>>> conversion of iostreams to void*.
>>>>
>>>> Isn't one of the key problems that bool conversion introduces is the
>>>> follow on
>>>> conversion to integral types?  If implicit bool -> integral conversion
>>>> wasn't allowed, T -> bool conversion would be less problematic, no?
>>>
>>> That is correct, and "less problematic" is exactly how I'd put it. There's a problem left. Assuming bool -> numeric conversion is impossible, there's still a problem. First, consider a class, array, pointer, or number x. This compiles:
>>>
>>> if (x) stmt
>>>
>>> This also compiles:
>>>
>>> x ? expr1 : expr2
>>>
>>> But this doesn't compile:
>>>
>>> bool b = x;
>>>
>>> Now consider we design tests to use opBool that effects implicit conversion to bool. Then, for a user-defined type x, all of the three samples above compile. Which means we have introduced a gratuitous incompatibility between user-defined and built-in types.
>>>
>>> Then consider another problem: a type that allows if (x) also wants to
>>> allow if (!x). It's the natural thing to want. Then we need to define
>>> opBool and opUnary!"!" to work in concert, redundantly. Bleh.
>>>
>>> I'm not sure how big problems these are. I think they are threatening enough that style manuals and coding standards mention both.
>>>
>>> Using double negation !!x throughout, there are only advantages and no disadvantage. I hit that design with Pacquiao punches over the past week or so, and couldn't find any shortcoming. It's consistent across positive and negated uses, easy to understand, easy to define, consistent with built-in types, and Walter likes it.
>>>
>>>
>>> Andrei
>>
>> Couldn't we solv that by instead of introducing opBool, introduce opTrue.
>> Which is defined as yielding a type testable for truth and is only
>> invoked
>> in the same situations that class references are used as thruth values?
>> To
>> me this looks like a simple solution.
> 
> OpTrue also implies opFalse, which is redundant.

It was the semantics I was after I just choose a different name to keep the concepts appart.
December 07, 2009
Michiel Helvensteijn wrote:
> Andrei Alexandrescu Wrote:
> 
>>> What will removing it gain you?
>> Sancta simplicitas.
> 
> Hm.. I don't really buy that argument.
> 
> I see you and Walter removing/witholding things (incomparability operators, logical operator overloading) from the language, because: "I can't imagine a use for it and removing it makes the language simpler."
> 
> Meanwhile, you're keeping C syntax for function-pointers around, 

C declaration syntax is on the chopping block. Walter hasn't actually removed any features yet from DMD releases.

and I'm missing syntactic sugar for my tribool.

> 
> The fact that you or I think there isn't a use for a feature, doesn't mean there isn't one. Programmers keep finding new and unintended uses for language features, which is a good thing. And if you want to simplify the language, I wouldn't start with the unary + when you've still got all that C stuff around.

Yes, but D is getting *really* big. The language complexity is a problem. We need to cut out everything we can possibly can. Unary + is a nice example of something that is almost completely useless.
December 07, 2009
Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Is there any good use of unary +? As an aside, Perl programs do use it occasionally for syntactic disambiguation :o).
>
> Andrei

Leave it in. WIth unary -, we should also have its archnemesis, the unary +.

-- 
Simen
December 07, 2009
On Mon, Dec 7, 2009 at 4:00 AM, Don <nospam@nospam.com> wrote:
> Michiel Helvensteijn wrote:
>>
>> Andrei Alexandrescu Wrote:
>>
>>>> What will removing it gain you?
>>>
>>> Sancta simplicitas.
>>
>> Hm.. I don't really buy that argument.
>>
>> I see you and Walter removing/witholding things (incomparability operators, logical operator overloading) from the language, because: "I can't imagine a use for it and removing it makes the language simpler."
>>
>> Meanwhile, you're keeping C syntax for function-pointers around,
>
> C declaration syntax is on the chopping block. Walter hasn't actually removed any features yet from DMD releases.
>
> and I'm missing syntactic sugar for my tribool.
>
>>
>> The fact that you or I think there isn't a use for a feature, doesn't mean there isn't one. Programmers keep finding new and unintended uses for language features, which is a good thing. And if you want to simplify the language, I wouldn't start with the unary + when you've still got all that C stuff around.
>
> Yes, but D is getting *really* big. The language complexity is a problem. We need to cut out everything we can possibly can. Unary + is a nice example of something that is almost completely useless.

I say you should completely chop it then.  Leaving it in for literals
only leaves a mess that's hard to justify.
I have often written things like

  glVertex2f(-boxRadius,-boxRadius);
  glVertex2f(+boxRadius,-boxRadius);
  glVertex2f(+boxRadius,+boxRadius);
  glVertex2f(-boxRadius,+boxRadius);

And often code like that starts out as something with constants:

  glVertex2f(-1,-1);
  glVertex2f(+1,-1);
  glVertex2f(+1,+1);
  glVertex2f(-1,+1);

I would find it quite confusing and annoying if the latter worked but
the former did not.
But I could live with it if neither worked.

--bb
December 07, 2009
Walter Bright wrote:
> 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.

+vote
December 07, 2009
Michiel Helvensteijn wrote:
> Andrei Alexandrescu Wrote:
> 
>>> What will removing it gain you?
>> Sancta simplicitas.
> 
> Hm.. I don't really buy that argument.
> 
> I see you and Walter removing/witholding things (incomparability
> operators, logical operator overloading) from the language, because:
> "I can't imagine a use for it and removing it makes the language
> simpler."

I disagree, and I think "not imagining a use for X" is a very weak argument for removing X. When a feature is made to walk the plank, we have much better arguments than that. Take typedef: it was ill-defined, defining it properly would have been a major effort, and all benefits could actually be emulated with a struct simpler and cheaper.

> Meanwhile, you're keeping C syntax for function-pointers around, and
> I'm missing syntactic sugar for my tribool.

C syntax for pointers to functions is there for a reason, but we're considering removing it. For one thing, TDPL doesn't mention it.

> The fact that you or I think there isn't a use for a feature, doesn't
> mean there isn't one. Programmers keep finding new and unintended
> uses for language features, which is a good thing. And if you want to
> simplify the language, I wouldn't start with the unary + when you've
> still got all that C stuff around.

I was mostly talking about overloading operator +. Operator + has a long history of being available for overloading in C++, which we can use to our advantage. It has been used to emulate DSLs, but I think we have much better means to define DSLs in D than to redefine all operators to mean some convention-chosen things.


Andrei
December 07, 2009
Mon, 07 Dec 2009 04:06:14 -0500, Michiel Helvensteijn wrote:

> Andrei Alexandrescu Wrote:
> 
>> > What will removing it gain you?
>> 
>> Sancta simplicitas.
> 
> Hm.. I don't really buy that argument.
> 
> I see you and Walter removing/witholding things (incomparability operators, logical operator overloading) from the language, because: "I can't imagine a use for it and removing it makes the language simpler."
> 
> Meanwhile, you're keeping C syntax for function-pointers around, and I'm missing syntactic sugar for my tribool.

You probably don't want to anger millions of users coming from the C community, do you?
December 07, 2009
"retard" <re@tard.com.invalid> wrote in message news:hfjnfv$1gvr$4@digitalmars.com...
> Mon, 07 Dec 2009 04:06:14 -0500, Michiel Helvensteijn wrote:
>
>> Andrei Alexandrescu Wrote:
>>
>>> > What will removing it gain you?
>>>
>>> Sancta simplicitas.
>>
>> Hm.. I don't really buy that argument.
>>
>> I see you and Walter removing/witholding things (incomparability operators, logical operator overloading) from the language, because: "I can't imagine a use for it and removing it makes the language simpler."
>>
>> Meanwhile, you're keeping C syntax for function-pointers around, and I'm missing syntactic sugar for my tribool.
>
> You probably don't want to anger millions of users coming from the C community, do you?

Nope, we don't. So let's just define D == C, and keep all of them happy.


December 08, 2009
Simen kjaeraas wrote:
> Leave it in. WIth unary -, we should also have its archnemesis, the unary +.

Can't have Superman without Lex Luthor!