Andrei Alexandrescu wrote:
> We're entering the finale of D2 and I want to keep a short list of things that must be done and integrated in the release. It is clearly understood by all of us that there are many things that could and probably should be done.

What do you mean by finale, exactly?

<snip>
> * Encode operators by compile-time strings. For example, instead of the plethora of opAdd, opMul, ..., we'd have this:
> 
> T opBinary(string op)(T rhs) { ... }
> 
> The string is "+", "*", etc. We need to design what happens with read-modify-write operators like "+=" (should they be dispatch to a different function? etc.)
<snip>

Perhaps something like

    T opModify(string op)(T rhs)

so that
    a += b
would be equivalent to the first of these to be valid:
    a = a.opModify!("+")(b)
    a = (a.opModify!("+")(b), a)  (if opModify returns void)
    a = a.opBinary!("+")(b)
    a = b.opBinary!("+")(a)

The idea is that an opModify method would likely modify the object in-place and return the modified object, but may return a new object to be assigned to a.

That said, I'm not sure if there's any real use case for it being a new object distinct from simple a + b.  But maybe there are cases where it may variously modify in-place or reallocate.  (Is this still how ~= works in current D2?)

But whatever we do, we shouldn't allow opModify to return something if that something isn't going to be assigned to a.

Stewart.

aarti_pl wrote:
<snip>
> I agree. opDollar is not particularly fitting to D language operator concept. opLength/opSize would fit better.
<snip>

Why I believe opLength and opSize are also wrong names:

http://www.digitalmars.com/d/archives/digitalmars/D/announce/Re_opDollar_12939.html
http://d.puremagic.com/issues/show_bug.cgi?id=3474

Stewart.

Stewart Gordon wrote:
> aarti_pl wrote:
> <snip>
>> I agree. opDollar is not particularly fitting to D language operator concept. opLength/opSize would fit better.
> <snip>
> 
> Why I believe opLength and opSize are also wrong names:
> 
> http://www.digitalmars.com/d/archives/digitalmars/D/announce/Re_opDollar_12939.html 
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=3474
> 
> Stewart.

FWIW, another suggestion: opCount

Though I'm unsure if that is also the wrong name by your criteria.

-- Justin

Justin Johansson wrote:
> Stewart Gordon wrote:
>> aarti_pl wrote:
>> <snip>
>>> I agree. opDollar is not particularly fitting to D language operator concept. opLength/opSize would fit better.
>> <snip>
>>
>> Why I believe opLength and opSize are also wrong names:
>>
>> http://www.digitalmars.com/d/archives/digitalmars/D/announce/Re_opDollar_12939.html 
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=3474
>>
>> Stewart.
> 
> FWIW, another suggestion: opCount
> 
> Though I'm unsure if that is also the wrong name by your criteria.
> 
> -- Justin
Like opSize(), opCount() only makes sense for integers.

Andrei Alexandrescu wrote:
> Walter Bright wrote:
>> Andrei Alexandrescu wrote:
>>> If we use @safe and @trusted to indicate unequivocally "no escape", then there is no analysis to be done - the hard part of the analysis has already been done manually by the user.
>>
>> The problem then becomes:
>>
>> T[] foo(T[] t) { return t; }
>>
>> T[] bar()
>> {
>>    T[3] a;
>>    return foo(a);
>> }
> 
> The "no escape" rule only applies to pointers, not arrays. Translating your example to pointers:
> 
> T* foo(T* t) { return t; }
> 
> T* bar() {
>     T[] a;
>     return foo(a.ptr);
> }
> 
> Steve Schweighoffer has pointed out a while ago that the compiler cannot assume a scope of a returned value to be any larger than the scopes of its parameters. Your example and the example above are canonical and the most complicated analysis I know of in SafeD. It is admittedly a huge complication, but just something that you'll need to pay attention to when implementing.

What if foo were a safe concat, like:

T[] foo(T[] t, T[] s) { return t ~ s; }

T[] bar(T[] s)
{  T[3] a;
   return foo(a, s);
}

That's perfectly safe, but how is the compiler not to give an error on that?

On Sat, 21 Nov 2009 09:06:53 +0300, Don <nospam@nospam.com> wrote:

> Justin Johansson wrote:
>> Stewart Gordon wrote:
>>> aarti_pl wrote:
>>> <snip>
>>>> I agree. opDollar is not particularly fitting to D language operator concept. opLength/opSize would fit better.
>>> <snip>
>>>
>>> Why I believe opLength and opSize are also wrong names:
>>>
>>> http://www.digitalmars.com/d/archives/digitalmars/D/announce/Re_opDollar_12939.html http://d.puremagic.com/issues/show_bug.cgi?id=3474
>>>
>>> Stewart.
>>  FWIW, another suggestion: opCount
>>  Though I'm unsure if that is also the wrong name by your criteria.
>>  -- Justin
> Like opSize(), opCount() only makes sense for integers.

opDim(ension)?

Denis Koroskin wrote:
> On Sat, 21 Nov 2009 09:06:53 +0300, Don <nospam@nospam.com> wrote:
> 
>> Justin Johansson wrote:
>>> Stewart Gordon wrote:
<snip>
>>>> Why I believe opLength and opSize are also wrong names:
>>>>
>>>> http://www.digitalmars.com/d/archives/digitalmars/D/announce/Re_opDollar_12939.html http://d.puremagic.com/issues/show_bug.cgi?id=3474
>>>>
>>>> Stewart.
>>>  FWIW, another suggestion: opCount
>>>  Though I'm unsure if that is also the wrong name by your criteria.
>>>  -- Justin
>> Like opSize(), opCount() only makes sense for integers.
> 
> opDim(ension)?

You've lost me....

Stewart.

Stewart Gordon wrote:
> Denis Koroskin wrote:
>> On Sat, 21 Nov 2009 09:06:53 +0300, Don <nospam@nospam.com> wrote:
>>
>>> Justin Johansson wrote:
>>>> Stewart Gordon wrote:
> <snip>
>>>>> Why I believe opLength and opSize are also wrong names:
>>>>>
>>>>> http://www.digitalmars.com/d/archives/digitalmars/D/announce/Re_opDollar_12939.html http://d.puremagic.com/issues/show_bug.cgi?id=3474
>>>>>
>>>>> Stewart.
>>>>  FWIW, another suggestion: opCount
>>>>  Though I'm unsure if that is also the wrong name by your criteria.
>>>>  -- Justin
>>> Like opSize(), opCount() only makes sense for integers.
>>
>> opDim(ension)?
> 
> You've lost me....
> 
> Stewart.

Me too.

Another suggestion: opRational.

I jest :-)

--Justin

Justin Johansson wrote:
> Stewart Gordon wrote:
>> Denis Koroskin wrote:
>>> On Sat, 21 Nov 2009 09:06:53 +0300, Don <nospam@nospam.com> wrote:
>>>
>>>> Justin Johansson wrote:
>>>>> Stewart Gordon wrote:
>> <snip>
>>>>>> Why I believe opLength and opSize are also wrong names:
>>>>>>
>>>>>> http://www.digitalmars.com/d/archives/digitalmars/D/announce/Re_opDollar_12939.html http://d.puremagic.com/issues/show_bug.cgi?id=3474
>>>>>>
>>>>>> Stewart.
>>>>>  FWIW, another suggestion: opCount
>>>>>  Though I'm unsure if that is also the wrong name by your criteria.
>>>>>  -- Justin
>>>> Like opSize(), opCount() only makes sense for integers.
>>>
>>> opDim(ension)?
>>
>> You've lost me....
>>
>> Stewart.
> 
> Me too.
> 
> Another suggestion: opRational.
> 
> I jest :-)
> 
> --Justin

Is that something like opOp?  The operation you define to define operations for new operations?

Chad J wrote:

> Andrei Alexandrescu wrote:
>> grauzone wrote:
>>>
>>> Also, you should fix the auto-flattening of tuples before it's too late. I think everyone agrees that auto-flattening is a bad idea, and that tuples should be nestable. Flattening can be done manually with an unary operator.
>>>
>>> (Introducing sane tuples (e.g. unify type and value tuples, sane and
>>> short syntax, and all that) can wait for later if it must. Introducing
>>> these can be downwards compatible, I hope.)
>> 
>> Non-flattening should be on the list but I am very afraid the solution would take a long time to design, implement, and debug. I must discuss this with Walter.
>> 
>> Andrei
> 
> Might I suggest a daring stop-gap:  kill tuples altogether.
> 
> Then we can implement them later correctly and it won't break backwards compatibility.
> 
> Ideally it isn't an all-or-nothing proposition either.  Maybe we can just kill the parts that are bad.  Like disallow tuples-of-tuples, but allow tuples that are already flat.
> 
> - Chad

By the time you would have restored phobos to about 50% of it's usefulness you could have implemented non-flattening tuples ten times over. I would switch back to D1 :)