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 about the implementation of Tuple
is wrong? It is not actually a structured type?
I don't know what you mean by "structured type". What I mean by "product
type" is this: http://en.wikipedia.org/wiki/Product_type
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 benefit.
I don't know how 'major' they'd really work out to be. It's not a
paradigm buster. There are some details, but I don't even think it would
need to be a breaking change to the language (maybe some very subtle
tweaks).
I am convinced you are underestimating. The notion that a function
returns one typed value is strongly embedded in the language and the
standard library.
Can you quantify 'little' benefit? I started this thread because I have
found myself wishing for this feature every other day. It would be of
huge value, and many others seem to agree.
I think you and others are concerned with different aspects
(incrementally pleasant syntax vs. efficiency).
D has it all, there are so many features in D which make it feel like a
modern language, but this is a missed(/rejected?) opportunity. It's a
natural thing to want to ask a computer to do, but we're mentally
trained into the returns-a-single-thing model from C and whatever and
apparently it was never considered at the initial design stage, but
apart from the expressive side, more importantly in D's case as a native
language, it is an opportunity to implement an important low level
feature that no other language offers me; an efficient multi-return
syntax+ABI.
D can return multiple values from a function by putting them in a tuple.
This approach has many advantages, mostly related to avoiding awkward
ambiguities (e.g. forwarding the result of a multi-return to a variadic
or overloaded function). Regarding syntax, I am not convinced by
arguments predicated on removing "Tuple!" from "Tuple!(int, int)". It's
not progress, and pouring more magic in tuples that is not available
anywhere else does not strike me as a good path to go.
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 b + c;
}
auto foo() {
return tuple(1, 1);
}
void main() {
writeln(a(foo().expand));
}
An adjustment may be needed from the output of a() to the arguments of
foo(). (Probably not in this case.) I understand that someone very
concerned with low-level performance would scrutinize such code
carefully. But I also believe that the same person is willing to forgo a
whole category of language and library features that don't fulfill a
demanding performance profile.
In the tight loops of every program I've ever written, I can't recall a
time when I haven't had a function that needs to return multiple things,
and C/C++ has always forced me into unnecessary memory access to express
this (ref parameters). For the first time in language/compiler history,
D would finally be able to eliminate the last of the redundant memory
accesses in my hottest code in a portable way, at a language/expression
level.
Are you saying it's impossible, that you don't think it should be done,
or it's already solved?
I understand your pledge, and all I'm saying is that it is very
difficult to implement (Walter and I discussed the matter many times
over the years) and the feature will benefit only very, very few.
Is it that you don't see the value in it? Is that what I need to
convince you of?
You haven't argued with any of the other points I raised, which leads me
to suspect you either see my points, or you think the entire premise of
my rant is wrong... if so, can you show how, and present a solution
that's workable within existing constructs that meets my criteria
without adding other implicit/logical baggage? Nobody has acknowledged
or disputed the majority of my points :/
Your points are understood, but please also understand what exceptional
circumstances you are invoking. You mention how transferring function
results costs extra operations. If that cost is significant, that means
the cost of the function proper is extremely low. So you want to call
extremely small functions in extremely core loops. The first advice
would be "avoid calling extremely small functions in extremely core loops"!
D is a native language, that's it's most attractive feature, and while I
appreciate all the high-level correct-ness D offers, it still needs to
get the low level right and ideally improve on existing offerings in
meaningful ways to motivate new users to switch. This is a big
un-checked checkbox for me and my colleagues, and I'd wager any low
level realtime programmer out there who has had to struggle with the
codegen in their inner loops.. doubly so if they ever work on non-x86
systems since the penalties are so much greater.
Are function returning tuples the first thing on your low-level
efficiency list?
Andrei
