On 11 March 2012 03:45, Robert Jacques sandf...@jhu.edu wrote:
On Sat, 10 Mar 2012 19:27:05 -0600, Manu turkey...@gmail.com wrote:
On 11 March 2012 00:25, Sean Cavanaugh worksonmymach...@gmail.com
wrote:
On 3/10/2012 4:37 AM, Manu wrote:
If I pass a structure TO a function by value, I
On 11 March 2012 04:35, Sean Cavanaugh worksonmymach...@gmail.com wrote:
On 3/10/2012 8:08 PM, Mantis wrote:
Tuple!(float, float) callee() {
do something to achieve result in st0,st1
fst st0, st1 into stack
load stack values into EAX, EDX
ret
}
void caller() {
call callee()
push EAX,
On 11 March 2012 05:04, Andrei Alexandrescu
seewebsiteforem...@erdani.orgwrote:
On 3/10/12 4:37 AM, Manu wrote:
I still fundamentally see a clear divide between a Tuple, which is a
deliberately structured association of multiple values, and 'multiple
return values' which is an explicit non
On 11 March 2012 05:04, Andrei Alexandrescu
seewebsiteforem...@erdani.orgwrote:
This analogy is tenuous for D because functions are defined to return one
type, e.g. typeof(fun(args)) is defined. Once we get into disallowing that
for certain functions, we're looking at major language changes
it is.
How do you express that? The problems seem very similar to me.
Language built-in tuples, of course.
See std.traits.ParameterTypeTuple.
It is extremely obvious how multiple return values should work.
On 03/11/2012 12:50 PM, Manu wrote:
Nobody has acknowledged
or disputed the majority of my points :/
I agree with the majority of your points.
On Sunday, 11 March 2012 at 03:04:38 UTC, Andrei Alexandrescu
wrote:
This analogy is tenuous for D because functions are defined to
return one type, e.g. typeof(fun(args)) is defined. Once we get
into disallowing that for certain functions, we're looking at
major language changes for little
On 11 March 2012 14:56, Timon Gehr timon.g...@gmx.ch wrote:
On 03/11/2012 12:50 PM, Manu wrote:
Nobody has acknowledged
or disputed the majority of my points :/
I agree with the majority of your points.
Cool, well that's encouraging :)
I can't really argue the implementation details, all
return values.
On 03/11/12 02:27, Manu wrote:
I've never seen the compiler do wildly unexpected things unless whole program
optimisation is enabled
The compiler can only ignore the ABI when it knows it sees the whole picture,
ie whole program, or whole unit in case of private/local functions.
which I don't
. It implements the assignment from built-in/library tuples to
multiple newly declared variables, but it does not implement multiple
return values.
How does the syntax work precisely?
Is it possible to do each of those things I mentioned earlier; assign to
existing locals, ignore individual return
On 11 March 2012 16:01, Artur Skawina art.08...@gmail.com wrote:
which I don't imagine D will be able to support any time real soon?
In fact, until GDC learns cross-module inlining, using these modes is the
only
way to make the compiler generate sane code
Yeah I'm very concerned by this
On 03/11/12 15:59, Manu wrote:
On 11 March 2012 16:01, Artur Skawina art.08...@gmail.com
mailto:art.08...@gmail.com wrote:
which I don't imagine D will be able to support any time real soon?
In fact, until GDC learns cross-module inlining, using these modes is the
only
way
On Sun, 11 Mar 2012 05:57:05 -0500, Manu turkey...@gmail.com wrote:
On 11 March 2012 04:35, Sean Cavanaugh worksonmymach...@gmail.com wrote:
On 3/10/2012 8:08 PM, Mantis wrote:
Tuple!(float, float) callee() {
do something to achieve result in st0,st1
fst st0, st1 into stack
load stack
/unpacking code will likely be slower than a store/load.
We just need proper multiple return values, then this can go away. And the
earlier any ABI breaking changes are implemented, the better, while there
are still few(/none?) closed source, binary distributed D libraries.
On 11 March 2012 18:45, Artur Skawina art.08...@gmail.com wrote:
Other than that, there is devirtualization - D does not have 'virtual';
the compiler
can still do it and even inline the virtual methods, but it needs to know
that
nothing overrides the functions - impossible w/o WPO for public
On 3/11/12 7:52 AM, Timon Gehr wrote:
It is extremely obvious how multiple return values should work.
(int, int) fun();
writeln(fun());
auto a = fun();
writeln(a);
What should happen?
Andrei
On 3/11/12 8:08 AM, David Nadlinger wrote:
On Sunday, 11 March 2012 at 03:04:38 UTC, Andrei Alexandrescu wrote:
This analogy is tenuous for D because functions are defined to return
one type, e.g. typeof(fun(args)) is defined. Once we get into
disallowing that for certain functions, we're
On 3/11/12 6:50 AM, Manu wrote:
On 11 March 2012 05:04, Andrei Alexandrescu
seewebsiteforem...@erdani.org mailto:seewebsiteforem...@erdani.org
There is no difference. A Tuple is a product type, exactly like
superposing arbitrary values together.
So you're saying that whatever I think
On 03/11/12 18:45, Manu wrote:
On 11 March 2012 18:45, Artur Skawina art.08...@gmail.com
mailto:art.08...@gmail.com wrote:
Other than that, there is devirtualization - D does not have 'virtual';
the compiler
can still do it and even inline the virtual methods, but it needs to know
On 3/11/12 8:23 AM, Manu wrote:
On 11 March 2012 14:56, Timon Gehr timon.g...@gmx.ch
mailto:timon.g...@gmx.ch wrote:
On 03/11/2012 12:50 PM, Manu wrote:
Nobody has acknowledged
or disputed the majority of my points :/
I agree with the majority of your points.
Cool,
will probably not be added to the language.
[snip.]
Good points. However, adding multiple return values after the
implementation is fleshed out still seems like a good idea.
On 03/11/2012 07:58 PM, Andrei Alexandrescu wrote:
On 3/11/12 7:52 AM, Timon Gehr wrote:
It is extremely obvious how multiple return values should work.
(int, int) fun();
writeln(fun());
auto a = fun();
writeln(a);
What should happen?
Andrei
That largely depends on fun.
For instance
On 03/11/2012 08:17 PM, Andrei Alexandrescu wrote:
If you create a variable of type
TypeTuple!(ReturnType1, ReturnType2), what's its layout?
That is context-dependent:
union U{
TypeTuple!(int, double) x; // superimposed according to union abi
}
struct S{
TypeTuple!(int, double) x;
(ranges,
delegates? I suspect that's why this was invented). Structure
packing/unpacking code will likely be slower than a store/load.
We just need proper multiple return values, then this can go away. And the
earlier any ABI breaking changes are implemented, the better, while there
are still few
-optimisation in all cases other than an int-pair struct (ranges,
delegates? I suspect that's why this was invented). Structure
packing/unpacking code will likely be slower than a store/load.
We just need proper multiple return values, then this can go away. And
the
earlier any ABI breaking changes
On 11 March 2012 20:57, Andrei Alexandrescu
seewebsiteforem...@erdani.orgwrote:
I don't know what you mean by structured type. What I mean by product
type is this:
http://en.wikipedia.org/wiki/**Product_typehttp://en.wikipedia.org/wiki/Product_type
The first line on that page states my
On 03/11/2012 09:41 PM, Manu wrote:
On 11 March 2012 20:57, Andrei Alexandrescu
...
Regarding low-level efficiency, the main issue is that structs and
function argument lists have distinct layouts. Consider:
import std.stdio, std.typecons;
int a(int b, int c) {
return
On 03/11/2012 10:57 PM, Robert Jacques wrote:
On Sun, 11 Mar 2012 15:38:21 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 03/11/2012 09:30 PM, Robert Jacques wrote:
Manu, why are you assuming that the struct is returned in any sort of
fixed memory layout?
Because that is what the ABI says.
On Sun, 11 Mar 2012 17:48:53 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 03/11/2012 10:57 PM, Robert Jacques wrote:
On Sun, 11 Mar 2012 15:38:21 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 03/11/2012 09:30 PM, Robert Jacques wrote:
Manu, why are you assuming that the struct is returned
On 03/11/2012 11:58 PM, Robert Jacques wrote:
Manu was arguing that MRV were somehow special and had mystical
optimization potential. That's simply not true.
Not exactly mystical, but it is certainly there.
void main(){
auto a = foo(); // MRV/struct return
bar(a.x); // defined in a
On 12 March 2012 00:50, Robert Jacques sandf...@jhu.edu wrote:
On Sun, 11 Mar 2012 05:56:03 -0500, Manu turkey...@gmail.com wrote:
On 11 March 2012 03:45, Robert Jacques sandf...@jhu.edu wrote:
On Sat, 10 Mar 2012 19:27:05 -0600, Manu turkey...@gmail.com wrote:
On 11 March 2012 00:25, Sean
On 12 March 2012 00:58, Robert Jacques sandf...@jhu.edu wrote:
That's an argument for using the right register for the job. And we can /
will be doing this on x86-64, as other compilers have already done. Manu
was arguing that MRV were somehow special and had mystical optimization
potential.
On Sun, Mar 11, 2012 at 7:44 PM, Manu turkey...@gmail.com wrote:
On 12 March 2012 00:58, Robert Jacques sandf...@jhu.edu wrote:
That's an argument for using the right register for the job. And we can /
will be doing this on x86-64, as other compilers have already done. Manu was
arguing that
On Sun, 11 Mar 2012 18:15:31 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 03/11/2012 11:58 PM, Robert Jacques wrote:
Manu was arguing that MRV were somehow special and had mystical
optimization potential. That's simply not true.
Not exactly mystical, but it is certainly there.
void main(){
On Sun, 11 Mar 2012 19:44:32 -0500, Manu turkey...@gmail.com wrote:
On 12 March 2012 00:58, Robert Jacques sandf...@jhu.edu wrote:
That's an argument for using the right register for the job. And we can /
will be doing this on x86-64, as other compilers have already done. Manu
was arguing
On 3/11/12 6:30 PM, Manu wrote:
D should
define an MRV ABI which is precisely the ABI for passing multiple args
TO a function, but in reverse, for any given architecture. This also has
the lovely side effect of guaranteeing correct argument placement for
chain-called functions.
I'm quoting
12.03.2012 4:00, Robert Jacques пишет:
On Sun, 11 Mar 2012 18:15:31 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 03/11/2012 11:58 PM, Robert Jacques wrote:
Manu was arguing that MRV were somehow special and had mystical
optimization potential. That's simply not true.
Not exactly mystical,
On Sun, 11 Mar 2012 18:30:33 -0500, Manu turkey...@gmail.com wrote:
On 12 March 2012 00:50, Robert Jacques sandf...@jhu.edu wrote:
On Sun, 11 Mar 2012 05:56:03 -0500, Manu turkey...@gmail.com wrote:
On 11 March 2012 03:45, Robert Jacques sandf...@jhu.edu wrote:
On Sat, 10 Mar 2012 19:27:05
On Sun, 11 Mar 2012 21:49:52 -0500, Mantis mail.mantis...@gmail.com wrote:
12.03.2012 4:00, Robert Jacques пишет:
On Sun, 11 Mar 2012 18:15:31 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 03/11/2012 11:58 PM, Robert Jacques wrote:
Manu was arguing that MRV were somehow special and had
, which is a
deliberately structured association of multiple values, and 'multiple
return values' which is an explicit non-association of multiple returned
things.
You need to address that principle before I can begin to accept the idea of
abusing a structured tuple as a substitute for this important
On Sat, 10 Mar 2012 00:30:05 -0600, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 3/9/12 9:35 PM, Robert Jacques wrote:
On Fri, 09 Mar 2012 22:16:44 -0600, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 3/9/12 3:59 PM, Timon Gehr wrote:
Notably, there is no
On 03/10/2012 05:26 AM, Andrei Alexandrescu wrote:
On 3/9/12 4:10 PM, Timon Gehr wrote:
(int, int) foo(int a, int b){return (a,b);}
assert(foo(foo(foo(foo(1,2==(1,2));
(int, int) goo(int a, int b, int c){return (a+b, c);}
assert(goo(foo(2,3),1) == (5,1));
This is a recipe for disaster
Robert Jacques:
The proposed unpacking syntax, IIRC, was:
(double a, int b) = fun();
which lowered to:
auto __tup = fun();
double x = __tup[0]; // __tup[0] has a type that is implicitly convertible
to double
int y = __tup[1]; // ditto
Why not instead lower to:
auto __tup =
On 03/10/2012 05:16 AM, Andrei Alexandrescu wrote:
On 3/9/12 3:59 PM, Timon Gehr wrote:
Yes, but we wouldn't have needed it if the built-in one would have been
considered sufficient.
The goal is considering the language sufficient for implementing a
useful structure such as Tuple in a
On 3/10/2012 4:37 AM, Manu wrote:
If I pass a structure TO a function by value, I know what happens, a
copy is written to the stack which the function expects to find there.
This is only true if the compiler is forced to use the ABI, when
inlining is impossible, or the type being passed is
On 11 March 2012 00:25, Sean Cavanaugh worksonmymach...@gmail.com wrote:
On 3/10/2012 4:37 AM, Manu wrote:
If I pass a structure TO a function by value, I know what happens, a
copy is written to the stack which the function expects to find there.
This is only true if the compiler is
On Sat, 10 Mar 2012 09:58:30 -0600, bearophile bearophileh...@lycos.com wrote:
Robert Jacques:
The proposed unpacking syntax, IIRC, was:
(double a, int b) = fun();
which lowered to:
auto __tup = fun();
double x = __tup[0]; // __tup[0] has a type that is implicitly convertible to
double
On Sat, 10 Mar 2012 19:27:05 -0600, Manu turkey...@gmail.com wrote:
On 11 March 2012 00:25, Sean Cavanaugh worksonmymach...@gmail.com wrote:
On 3/10/2012 4:37 AM, Manu wrote:
If I pass a structure TO a function by value, I know what happens, a
copy is written to the stack which the function
11.03.2012 3:45, Robert Jacques пишет:
[...]
Manu, please go read the D ABI (http://dlang.org/abi.html). Remember,
your example of returning two values using Tuple vs 'real' MRV? The D
ABI states that those values will be returned via registers. Returning
something larger? Then the NVRO kicks
On 3/10/2012 8:08 PM, Mantis wrote:
Tuple!(float, float) callee() {
do something to achieve result in st0,st1
fst st0, st1 into stack
load stack values into EAX, EDX
ret
}
void caller() {
call callee()
push EAX, EDX into a stack
fld stack values into st0, st1
do something with st0, st1
}
As
Lot of cool discussions going on right now with UFCS and language
Tuples. I don't know if it's been said before, but one thing I'd
really like with Tuples syntax is the ability to access multiple
members the same way. Plus it could be nice to be able to define
multiple function parameters the
On 3/10/12 4:37 AM, Manu wrote:
I still fundamentally see a clear divide between a Tuple, which is a
deliberately structured association of multiple values, and 'multiple
return values' which is an explicit non-association of multiple returned
things.
There is no difference. A Tuple
On Sat, 10 Mar 2012 20:35:02 -0600, Sean Cavanaugh worksonmymach...@gmail.com
wrote:
On 3/10/2012 8:08 PM, Mantis wrote:
Tuple!(float, float) callee() {
do something to achieve result in st0,st1
fst st0, st1 into stack
load stack values into EAX, EDX
ret
}
void caller() {
call callee()
push
://dl.dropbox.com/u/**36715190/Images/par_order.jpghttp://dl.dropbox.com/u/36715190/Images/par_order.jpg
Is it impossible to make efficient multiple return values without the need
to trade off the help from tools?
Eh? How so?
Visual studio show's the return value and function name in the same tooltip
On 03/09/2012 01:23 AM, Manu wrote:
I can imagine syntax using parentheses, but I don't think I'm qualified
to propose a robust syntax, I don't know enough about the finer details
of the grammar.
Perhaps if other people agree with me, they could present some creative
solutions to the syntax?
I
On Fri, Mar 09, 2012 at 03:27:14PM +0100, Timon Gehr wrote:
On 03/09/2012 01:23 AM, Manu wrote:
[...]
int x; ... (x, float y) = func(); // assign to predeclared variable(/s)?
(x, , z) = func(); // ignore the second result value (elimination of the
second result's code path)
Those two
On 9 March 2012 16:27, Timon Gehr timon.g...@gmx.ch wrote:
On 03/09/2012 01:23 AM, Manu wrote:
I can imagine syntax using parentheses, but I don't think I'm qualified
to propose a robust syntax, I don't know enough about the finer details
of the grammar.
Perhaps if other people agree with
On Mar 9, 2012 10:28 AM, H. S. Teoh hst...@quickfur.ath.cx wrote:
On Fri, Mar 09, 2012 at 03:27:14PM +0100, Timon Gehr wrote:
On 03/09/2012 01:23 AM, Manu wrote:
[...]
int x; ... (x, float y) = func(); // assign to predeclared
variable(/s)?
(x, , z) = func(); // ignore the second result
On 03/09/2012 04:38 PM, Manu wrote:
On 9 March 2012 16:27, Timon Gehr timon.g...@gmx.ch
mailto:timon.g...@gmx.ch wrote:
On 03/09/2012 01:23 AM, Manu wrote:
I can imagine syntax using parentheses, but I don't think I'm
qualified
to propose a robust syntax, I don't
On 9 March 2012 17:57, Timon Gehr timon.g...@gmx.ch wrote:
On 03/09/2012 04:38 PM, Manu wrote:
On 9 March 2012 16:27, Timon Gehr timon.g...@gmx.ch
mailto:timon.g...@gmx.ch wrote:
On 03/09/2012 01:23 AM, Manu wrote:
I can imagine syntax using parentheses, but I don't think I'm
?
There are two parts, syntax and semantics.
Semantics:
D is already able to express those:
template Tuple(T...){alias T Tuple;} // not the same as std.typecons.Tuple!
// function with multiple return values:
Tuple!(int,double) foo(int a, double b){
Tuple!(int, double) result; // ok, _no imposed
On 03/09/2012 05:14 PM, Manu wrote:
What I mean is this:
retTuple = func();
someStruct.x = retTuple[0];
y = retTuple[1];
// retTuple[2] is ignored, but the intent is not clear in the code as it
was in my prior example, I like how my prior example makes this intent
explicit
int err =
On Fri, Mar 09, 2012 at 07:16:19PM +0100, Timon Gehr wrote:
[...]
Another issue is that people would complain about auto-flattening all
the time once built-in tuples get more accessible, even though it is
not actually a problem. It would be just due to the fact that it does
not occur in most
H. S. Teoh:
Perl auto-flattens lists.
Maybe they have fixed this big design mistake in Perl6.
Bye,
bearophile
On Fri, Mar 09, 2012 at 02:01:34PM -0500, bearophile wrote:
H. S. Teoh:
Perl auto-flattens lists.
Maybe they have fixed this big design mistake in Perl6.
[...]
Whether or not it was a mistake is debatable. It does have its uses...
though forcing everyone to use references to prevent
Manu wrote:
By contrast, multiple return values are quite the opposite. They
are explicitly NON-STRUCTURED.
The presumption in this case is that multiple resturn
values would follow the exact same set of rules as passing
multiple args TO a function, but in reverse.
this seams to state
On 9 March 2012 22:39, Manfred Nowak svv1...@hotmail.com wrote:
Manu wrote:
By contrast, multiple return values are quite the opposite. They
are explicitly NON-STRUCTURED.
The presumption in this case is that multiple resturn
values would follow the exact same set of rules as passing
I'm finding HEAPS of SIMD functions want to return pairs
(unpacks in
particular): int4 (low, hight) = unpack(someShort8);
Currently I have to duplicate everyting: int4 low =
unpackLow(someShort8); int4 high = unpackHigh(someShort8);
I'm getting really sick of that, it feels so... last
Manu wrote:
I'm just talking about the ABI for returning multiple values, not
chaining
Does this mean, that you want a special type of function? For example
this would be disallowed statement: `auto result= f( g( parameters));',
if `f' and `g' are functions returning multiple values?
' are functions returning multiple values?
This needs to work. Multiple return values should integrate with the
existing language support for tuples.
On 3/9/12 10:16 AM, Timon Gehr wrote:
There are two parts, syntax and semantics.
Semantics:
D is already able to express those:
template Tuple(T...){alias T Tuple;} // not the same as std.typecons.Tuple!
// function with multiple return values:
Tuple!(int,double) foo(int a, double b){
Tuple
values:
Tuple!(int,double) foo(int a, double b){
Tuple!(int, double) result; // ok, _no imposed memory layout_
result[0] = a; // ok
result[1] = a+b; // ok
return result;
}
Multiple return values are currently *disallowed explicitly*:
DMD sez: Error: functions cannot return a tuple
Just specify the ABI
statement: `auto result= f( g( parameters));',
if `f' and `g' are functions returning multiple values?
This needs to work. Multiple return values should integrate with the
existing language support for tuples.
What should that do exactly? A function that returns multiple values is
passed
, not
chaining
Does this mean, that you want a special type of function? For
example
this would be disallowed statement: `auto result= f( g(
parameters));',
if `f' and `g' are functions returning multiple values?
This needs to work. Multiple return values
multiple values?
This needs to work. Multiple return values should integrate with the
existing language support for tuples.
What should that do exactly? A function that returns multiple values is
passed as an argument to another function... what exactly is fed to
which arguments
On 3/9/12 3:59 PM, Timon Gehr wrote:
Yes, but we wouldn't have needed it if the built-in one would have been
considered sufficient.
The goal is considering the language sufficient for implementing a
useful structure such as Tuple in a library. Same goes about associative
arrays.
-
On 3/9/12 4:10 PM, Timon Gehr wrote:
(int, int) foo(int a, int b){return (a,b);}
assert(foo(foo(foo(foo(1,2==(1,2));
(int, int) goo(int a, int b, int c){return (a+b, c);}
assert(goo(foo(2,3),1) == (5,1));
This is a recipe for disaster because of the implicit expansion.
Consider
On Fri, 09 Mar 2012 22:16:44 -0600, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 3/9/12 3:59 PM, Timon Gehr wrote:
Notably, there is no convenient unpacking syntax. Walter does not merge
the patches of Kenji Hara that would fix this because presumably he
fears it could get in
On 3/9/12 9:35 PM, Robert Jacques wrote:
On Fri, 09 Mar 2012 22:16:44 -0600, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 3/9/12 3:59 PM, Timon Gehr wrote:
Notably, there is no convenient unpacking syntax. Walter does not merge
the patches of Kenji Hara that would fix this
I find myself really wishing for proper multiple return values almost every
day, particularly when I work with maths heavy code, and especially for
efficiently returning error codes in functions I'd rather not throw from.
Many maths-y functions return some sort of pair; intersections return (ray
On Thu, Mar 08, 2012 at 10:08:41PM +0200, Manu wrote:
I find myself really wishing for proper multiple return values almost every
day, particularly when I work with maths heavy code, and especially for
efficiently returning error codes in functions I'd rather not throw from.
Many maths-y
On 8 March 2012 22:13, H. S. Teoh hst...@quickfur.ath.cx wrote:
On Thu, Mar 08, 2012 at 10:08:41PM +0200, Manu wrote:
I find myself really wishing for proper multiple return values almost
every
day, particularly when I work with maths heavy code, and especially for
efficiently returning
08.03.2012 22:08, Manu пишет:
I find myself really wishing for proper multiple return values almost
every day, particularly when I work with maths heavy code, and
especially for efficiently returning error codes in functions I'd
rather not throw from.
Many maths-y functions return some sort
On 9 March 2012 00:29, Mantis mail.mantis...@gmail.com wrote:
08.03.2012 22:08, Manu пишет:
I find myself really wishing for proper multiple return values almost
every day, particularly when I work with maths heavy code, and especially
for efficiently returning error codes in functions I'd
On 9 March 2012 00:29, Mantis mail.mantis...@gmail.com wrote:
08.03.2012 22:08, Manu пишет:
I find myself really wishing for proper multiple return values almost
every day, particularly when I work with maths heavy code, and especially
for efficiently returning error codes in functions I'd
I can't talk about multiple return values, but D allows you to do some
pretty crazy things. The following might not be very efficient, but it
does show the language is quite flexible. E.g.:
http://ideone.com/qy8i3
.
By contrast, multiple return values are quite the opposite. They are
explicitly NON-STRUCTURED. These serve a totally different purpose; to
return multiple unstructured things from a function.
Imagine an inline function which returns 2 results, only one of which
is captured. It is easy and intuitive
to behave like
one, precisely as any programmer will expect.
By contrast, multiple return values are quite the opposite. They are
explicitly NON-STRUCTURED. These serve a totally different purpose; to
return multiple unstructured things from a function.
Imagine an inline function which returns
different things,
and shouldn't be lumped into the same syntax for my money.
I am asking for multiple return values in D since some years, so I share your
desire. But keep in mind that in D currently there are Phobos Tuples and DMD
typetuples. Adding a third type of tuple-like things in a single
that
could
only possibly confuse people, they are conceptually quite different
things,
and shouldn't be lumped into the same syntax for my money.
I am asking for multiple return values in D since some years, so I share
your desire. But keep in mind that in D currently there are Phobos
, but order would be clearly
stated in the auto-complete pop-up, and in the reference. Also
mismatching types would throw errors.
You can't mess with the parameters order in this case:
http://dl.dropbox.com/u/36715190/Images/par_order.jpg
Is it impossible to make efficient multiple return values
Manu:
This is most certainly NOT a tuple-like thing. I don't think I can stress
that point any harder :)
I understand. But in other languages tuples are used for such purpose, so there
is some risk people will think of them as a third kind of tuples, despite they
are a different thing.
What
to see 'out' arguments deprecated when
multiple return values are introduced as a bit of built-in syntax sugar for
tuple de-structuring.
Beside their bad look, D 'out' arguments have some semantic characteristic
that's bad:
Currently D allows you to write code like this, where foo lacks any
Jacob Carlborg wrote:
C#, Java and similar language doesn't support free functions
like D does. Then they have to resort to hacks like static
methods, i.e. Console.WriteLine.
D's free functions and simple module design are definitely points
in it's favor. However that wasn't really my point.
On Thu, Jan 5, 2012 at 2:47 AM, F i L witte2...@gmail.com wrote:
Jacob Carlborg wrote:
C#, Java and similar language doesn't support free functions like D does.
Then they have to resort to hacks like static methods, i.e.
Console.WriteLine.
D's free functions and simple module design are
Andrew Wiley wrote:
You're pointing out two completely different things here. C#
PascalCases methods and D camelCases them. That's a completely
seperate issue from the actual names.
I think you're reading too much into what I wrote, I wasn't
talking about the case or modules vs static
a strong +1 towards proper multiple return
values. The point is NOT just to have the syntactical feature (ie. struct
return value semantics via tuples). The point is a language guarantee that
the architecture will do its best job to return each value in consecutive
registers OF ITS OWN TYPE, avoiding
deadalnix:
I do agree with Andrei. Those are 2 orthogonals problems. The
optimization problem is clearly something that can be improved in D ABI.
Then, returning a tuple could be improved using thoses rules.
I agree.
The multiple retur value problem is syntaxic sugar. It may be
to do.
I'm not clear what side of the fence you sit... I raise this issue because
I feel fixing multiple return values IS a syntactic problem. If the syntax
was good, ie. capable of expressing what you actually want from multiple
return values, but the code gen was not, I wouldn't care
101 - 200 of 223 matches
Mail list logo
