I didn't see all posts. but "stdout ~= tuple(a,b,c,d)" is best for Output, I think. and need more short tuple syntax like a:b:c:d.

Example:
stdout ~= a:b:c:d; //call stdout.opCat(a,b,c,d)
stdout ~= e:f;
stdout ~= g:h;

I have no idea for Input best solution without opPopAssign_r.

Example:
int a; char[] b;
a:b = stdin.pop; //call stdin.opPopAssign_r!(typeof(a:b))();
                 //return type is typeof(a:b).
                 //"decide template from return type" is needed.

These ideas have problem for binary size :-(
#Sorry for my poor English

Walter Bright wrote

>> would this be easily parsable?
>> other objections?
>> a = b (+) c;
> Yes.
Then this seems to be the way to go, thanks Chad.

And because we are at it: please provide the ability to abstract operators into families of operators by allowing an index.

This might look like (+:0), (+:1), (+:2), ... where (+) is a shorthand for (+:0).

Because of the overloading capabilities I do not see any other urgent need for this than to allow redundancy, but I might be wrong.

-manfred

Manfred Nowak wrote:

> Walter Bright wrote
> 
>> The problem with using unicode operators is that unicode isn't as well supported as it should be. It's one thing to support unicode in the language, it's another to require one to use a unicode capable text editor to edit source code.
> 
> The degree sign does not require unicode; it is in the normal ISO/IEC 8859-1 or latin1 table. Every editor should be capable to display it. Every system should be able to enter it.
> 
> The degree sign "°" is under windows reachable via <alt>0176.
> 
> The masculine ordinal indicator "º" via <alt>0186.
> 
> The currency sign "¤" via <alt>0164.
> 
> So: there is no such problem.
> 
> -manfred

Very good example of exactly why that would be a problem :)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Dancing the Tango

Don Clugston wrote:

> I agree. There's another problem -- it really doesn't scale well. With printf, you can do "%3.5f" to print a floating point number with a given precision. With <<, that same operation is really horrible.

But it has the added advantage that there is no need for run-time parsing of that string. C++ parses all << stuff at compile time.

-- 
Michiel

Michiel wrote:
> Don Clugston wrote:
> 
>> I agree. There's another problem -- it really doesn't scale well. With
>> printf, you can do "%3.5f" to print a floating point number with a given
>> precision. With <<, that same operation is really horrible.
> 
> But it has the added advantage that there is no need for run-time
> parsing of that string. C++ parses all << stuff at compile time.
> 

I wonder how much difference that makes given that most IO tends to be slow anyway.   On a 1 GHz proc, with a disk that has 10msec seek time that means a hit to the disk can cost you ten million cycles, right?

Spending a few cycles to parse a format string at runtime isn't going to kill you.

--bb

Bill Baxter wrote:

>> But it has the added advantage that there is no need for run-time parsing of that string. C++ parses all << stuff at compile time.
>>
> 
> I wonder how much difference that makes given that most IO tends to be slow anyway.   On a 1 GHz proc, with a disk that has 10msec seek time that means a hit to the disk can cost you ten million cycles, right?
> 
> Spending a few cycles to parse a format string at runtime isn't going to kill you.

Well, you're right of course. But strictly speaking it's still an advantage. ;)

-- 
Michiel

Lars Ivar Igesund wrote

> Very good example of exactly why that would be a problem :)

Thx. I simply should have edited a .d-file to avoid this stupid error.

-manfred

Manfred Nowak wrote

> Because of the overloading capabilities I do not see any other urgent need for this than to allow redundancy, but I might be wrong.

Addendum:

Bill has given the example of normal and dotwise matrix operations. Because these cannot be expressed by overloading, there is a need for indexing.

-manfred

Michiel wrote:
> Bill Baxter wrote:
> 
>>> But it has the added advantage that there is no need for run-time
>>> parsing of that string. C++ parses all << stuff at compile time.
>>>
>> I wonder how much difference that makes given that most IO tends to be
>> slow anyway.   On a 1 GHz proc, with a disk that has 10msec seek time
>> that means a hit to the disk can cost you ten million cycles, right?
>>
>> Spending a few cycles to parse a format string at runtime isn't going to
>> kill you.
> 
> Well, you're right of course. But strictly speaking it's still an
> advantage. ;)

C++ iostreams has the further "advantage" of being neither exception-safe nor thread-safe (since it manipulates global state in order to do formatting). This is only excusable because iostreams was added to C++ years before exception handling was and before anyone knew anything about threaded programming.

Walter Bright wrote:
> Michiel wrote:
>> Bill Baxter wrote:
>>
>>>> But it has the added advantage that there is no need for run-time
>>>> parsing of that string. C++ parses all << stuff at compile time.
>>>>
>>> I wonder how much difference that makes given that most IO tends to be
>>> slow anyway.   On a 1 GHz proc, with a disk that has 10msec seek time
>>> that means a hit to the disk can cost you ten million cycles, right?
>>>
>>> Spending a few cycles to parse a format string at runtime isn't going to
>>> kill you.
>>
>> Well, you're right of course. But strictly speaking it's still an
>> advantage. ;)
> 
> C++ iostreams has the further "advantage" of being neither exception-safe nor thread-safe (since it manipulates global state in order to do formatting). This is only excusable because iostreams was added to C++ years before exception handling was and before anyone knew anything about threaded programming.

It's a myth that iostreams benefit much the speed advantage of not needing to do type retrieval at runtime. They are marred by a convoluted design and the need to synchronize with C's stdio library. By the time you saved that penny, you've spent all of those pounds already.

Andrei