"Immanuel Scholz" <digitals-mars@kutzsche.net> wrote in message news:a6ainp$umk$1@digitaldaemon.com...

> -> has a different meaning. Although it is not used in D, I prefer another symbol.
>
> Maybe -=> or >>> ?

I remember >>> was unsigned shift. -=> just looks somewhat weird.

And what's the problem with -> ?  Yes, it had a special meaning
in C, but it's not used in D now, and it's quite mnemonic -
an arrow pointing "to" or "from" the stream...

"Pavel Minayev" <evilone@omen.ru> schrieb im Newsbeitrag news:a6amrk$1091$1@digitaldaemon.com...
> "Immanuel Scholz" <digitals-mars@kutzsche.net> wrote in message news:a6ainp$umk$1@digitaldaemon.com...
>
> > -> has a different meaning. Although it is not used in D, I prefer
another
> > symbol.
> >
> > Maybe -=> or >>> ?
>
> I remember >>> was unsigned shift. -=> just looks somewhat weird.

Huh... Yes.

-}  and {-  ? or [- and -] or (- and -) ... ? :-)


> And what's the problem with -> ?  Yes, it had a special meaning
> in C, but it's not used in D now, and it's quite mnemonic -
> an arrow pointing "to" or "from" the stream...

The Problem I would have is, that other coder would begin implementing operators after meanings, they saw before, and not after the meaning in the new language. If you are able to overload <<, I bet, some coder disagree with D-conventions and overload << to stream-output...

Imi, the paranoic one. (The world is bad... %-) )

"Immanuel Scholz" <digitals-mars@kutzsche.net> wrote in message news:a6an6p$10ft$1@digitaldaemon.com...

> The Problem I would have is, that other coder would begin implementing operators after meanings, they saw before, and not after the meaning in the new language. If you are able to overload <<, I bet, some coder disagree with D-conventions and overload << to stream-output...

...unless the author of the language and the community STRONGLY DISCOURAGES such use of operators << and >>. Such guys could overload << and >> for themselves, but hopefully libraries which define these operators for such purposes will be boycotted.

Also, the simplest way to enfore using operators other than
<< and >> would be to use their D replacements in Phobos. If
streams would use, say, <- and ->, and most programs use
streams for some purpose, there probably wouldn't be anybody
stupid enough to turn against the mainstream and overload
<< and >> just to follow C++ conventions... if every D user
from the very beginning knows that <- is output and -> is input,
it will be very hard to convince them to use some other scheme...

Also, define -> to be a _binary_ operator, and there is no way to overload it so it is the same as in C. =)

Pavel Minayev wrote:

> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a68s84$872$1@digitaldaemon.com...
>
> >     Whatever, essentially a notation that says by reference or by
> >     value is needed. Assignment by value means deep copy,
> >     otherwise destroying one object will render both invalid, not
> >     what you would expect in 99% of the cases.
>
> You don't actually "destroy" anything in D. Even operator
> delete doesn't do that if it isn't safe, AFAIK - or am
> I wrong, Walter?

Walter may have to correct my memory here, but I think that delete forces destruction of the object.  The reason I think that is that I remember arguing with Walter about it, because I thought that it was a bad idea :)

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Pavel Minayev wrote:

> Also, I'd add two more built-in operators, "in" and "out". These could be used for streams, stacks, queues, and anything similar that allows to put values in and take them out:

If you allow infix function calls, then they're not even operators.  You
just define
    int stdio::out(char[])
to write.  For the input side, you have to change the usage a little to
get pointers, but then you define:
    stdio *stdio::in(int*);
    stdio *stdio::in(char[]);
    etc.

Maybe I'm missing something...but it seems like it should work, AFAIK.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C88F341.A4FB9F7E@deming-os.org...

> If you allow infix function calls, then they're not even operators.  You
> just define
>     int stdio::out(char[])

Could be. But I thought a separate syntax for operators would be better... well, actually I don't care. Let's leave this to Walter to decide. =)

> to write.  For the input side, you have to change the usage a little to
> get pointers, but then you define:
>     stdio *stdio::in(int*);
>     stdio *stdio::in(char[]);
>     etc.
>
> Maybe I'm missing something...but it seems like it should work, AFAIK.

Er... "stdio" is already a pointer. Remember, there are no stack objects in D!

Pavel Minayev wrote:

> > to write.  For the input side, you have to change the usage a little to
> > get pointers, but then you define:
> >     stdio *stdio::in(int*);
> >     stdio *stdio::in(char[]);
> >     etc.
> >
> > Maybe I'm missing something...but it seems like it should work, AFAIK.
>
> Er... "stdio" is already a pointer. Remember, there are no stack objects in D!

Right.  That function I proposed was something that RETURNS a pointer...so
that your chain calls could work (it returns 'this'):
        stdin in &foo in buf;

Of course, this would only work if the infix funciton notation allows pointers on the left side.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C8909C6.3DEB9FBF@deming-os.org...

> Right.  That function I proposed was something that RETURNS a pointer...so
> that your chain calls could work (it returns 'this'):
>         stdin in &foo in buf;

No, I mean that since StdIn is a class, you don't need
to use * to state it as a pointer:

    class StdIn
    {
        StdIn read(out int n)    // returns a reference to StdIn
        {
            ...
            return this;
        }
    }
    StdIn stdin;

    stdin read foo read bar read etc;

Also, "in" and "out" are reserved D keywords, so they can't be used as function names.

> Of course, this would only work if the infix funciton notation allows
pointers
> on the left side.

I'd be pretty happy to have built-in input/output operators and the ability to overload them, for now.

Pavel Minayev wrote:

> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C8909C6.3DEB9FBF@deming-os.org...
>
> > Right.  That function I proposed was something that RETURNS a pointer...so
> > that your chain calls could work (it returns 'this'):
> >         stdin in &foo in buf;
>
> No, I mean that since StdIn is a class, you don't need
> to use * to state it as a pointer:

Oops, you're right :(

> Also, "in" and "out" are reserved D keywords, so they can't be used as function names.

Oops, right again. :(

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Pavel Minayev a écrit :

> if every D user
> from the very beginning knows that <- is output and -> is input,
> it will be very hard to convince them to use some other scheme...
>

while you are reconsidering the way stream are implemented, i personally
'feel' better -> as an output
and <- as an input..(sorry for the trouble).

roland