"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:d6vqvt$2068$1@digitaldaemon.com...
> >Walter is not afraid to do new things, and what youve suggested can be implemented with structs. So there.
>
> Loops can be implemented with gotos. So let's remove them.
>
>

Sarcasm aside, your point is valid.
Higher level language functionality can always be implemented with sufficient
low level code... but that doesn't mean it's not good to have.

Walter... when you get time, please add in a short comment here about which syntax
you like best for multiple return types, and how you feel at this time about the possibile
future of multiple return types and return type overloading in the D language.

TZ

"G.Vidal" <gyvidal@wanadoo.fr> wrote in message news:pan.2005.05.24.20.09.54.952681@wanadoo.fr...
>
> > There are _so_ many languages that have tupls build in with exactly the same syntax, so what is "crazy" about it?
>
> What I meant by "crazy" is "totally different from the C/C++/C#/Java syntaxes"
>
> I'm just tired of seeing so many ideas from so many people and finally there's no response from the D compiler programmer.
>
> So what are we suppose to think ? He reads them and is still thinking about it, reads and thinks the idea is bad, or maybe he doesn't read them at all, how can we know ?
>
> If he doesn't agree with the idea, we don't even know why. Maybe there should be more programmers for D.
>
>
>

Well, if ideas are discussed here and never end up in the D language,
the discussions may still influence the development of other languages in the future.
Keep in mind that this particular language is not the first one to be named D and
just possibly "may not" be the last.  While I very much hope it succedes, what's even
more important (in my opinion) is the trail that it's blazing in the process.

TZ

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d702g8$2a95$1@digitaldaemon.com...
>
*snip*
>
> Maybe Walter will consider this for 1.0. Maybe he'll consider it for 2.0. Maybe he'll do it for 0.126. Who knows... My guess would be it belongs in the post 1.0 bucket.
>
>

Agreed.

TZ

"Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:d7033h$2ane$1@digitaldaemon.com...
>
*snip*
>
> (a, b, c) = func(1, 2, 3);
>
> Really looks like Perl to me, and thus ugly.  I would say that it'd need some sort of keyword to look C-like:
>
*snip*
>
> -[Unknown]

I would rather have it look D-like than C-like... and...
(a,b,c) = func(1,2,3);
is looking more and more D-like to me every day.
After all, D may be "based on" the C language,
but I don't think the intention was ever for it to be
merely another version of C with a different name.

TZ

"James Dunne" <james.jdunne@gmail.com> wrote in message news:d6v9bv$1906$1@digitaldaemon.com...
> In article <opsq9rynem23k2f5@nrage.netwin.co.nz>, Regan Heath says...
*snip*
>
> My 2nd proposition was to remove all implicit casting from parameters and return types if the function had more than one return type that it was overloaded upon. Only by being completely explicit can we eliminate ambiguity.
>
*snip*
>
> Regards,
> James Dunne

I wonder if it would be helpful to have a special syntax for declarations that would prohibit any implicit casting to or from parameters of that declaration.

// Example:

explicit int a(int b);

void main(){
int c;
byte d;
c=a(d); // error
}

or perhaps it would be better to have to specify each explicit declaration individually. I think that would be easier on the compiler...

// Example:

explicit int a(explicit int b);

void main(){
int c;
byte d;
c=a(d); // error
}

TZ

In article <d7fu8q$2u1h$1@digitaldaemon.com>, TechnoZeus says...
>
>"Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:d7033h$2ane$1@digitaldaemon.com...
>>
>*snip*
>>
>> (a, b, c) = func(1, 2, 3);
>>
>> Really looks like Perl to me, and thus ugly.  I would say that it'd need some sort of keyword to look C-like:
>>
>*snip*
>>
>> -[Unknown]
>
>I would rather have it look D-like than C-like... and...
>(a,b,c) = func(1,2,3);
>is looking more and more D-like to me every day.
>After all, D may be "based on" the C language,
>but I don't think the intention was ever for it to be
>merely another version of C with a different name.
>
>TZ
>
>

In PHP you can do

list($a, $b, $c) = $array;

instead of

$a = $array[0];
$b = $array[1];
$c = $array[2];

Which is useful when you are breaking apart things with

list($a, $b, $c) = explode(",", "one,two,thee");

But I am hard pressed to find another example. AND, it's very limited.
Why? What if there is only "one,two" in the text? ERROR.
What if there is "one,two,three,four" in the text? You never get "four".

What is wrong with using

char[][] array = split(",", "one,two,three,four");


In the defense of this concept. I can see how

(r, g, b) = Color.Extract;

Might make SOME sense, but it's also DUMB. cause seriously, you could just use a variadic function..

Color.Extract(&r, &g, &b);
Color.Extract(&r, &g, &b, &a);

To me, I would need to see why something like

(... variadic output...) = function(parameters);

is so needed, and it is requiring so many lines of code to work around it's absence before I could support it's addition to D.

LONG before we needed something like this, we should be working on serialization of boxes or something.

My 2 cents.. :)

Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal@hotmail.com

One benevolent (genius) dictator is far better than any other way. As D is now (minus possible bugs) it will be a fantastic success. You read it here first! The only thing that could mar it would to put too much stuff into it like is always the case when something is "designed by committee". At this moment D is fast and sexy. Let it be that way. The difficult thing is not to decide what to put into a language, but what not to put in!