Syntactic and compatibility problems aside, I'd go with something like this:
[string, int] do_shady_things() { return ["foo", 17]; }
... [string s, int e] = do_shady_things();
The general idea of this is much better than "returning an array" since it clearly defines WHAT is returned and can have checking that the right stuff actually IS returned.
/ David Hedbor
Previous text:
2003-04-16 17:47: Subject: Pointers/lvalues
I note that you only dismiss one of three reasons I've given, and at least one of the other has in my opinion enough merit to warrant the feature by itself.
My opinion is that these "higher" problem should be addressed and solutions thought out for them.
I can agree with that. It doesn't solve the multi-return problem in a really satisfactory way.
There can however be other uses for passing pointers, such as functions that conditionally modify some arguments, like sscanf when the input ends short, or needs to look at their old values. In such cases a multi-return system isn't really satisfactory since the same argument would be required to be passed as an argument and used again as the target of a return value.
An impulse solution (that will not do) for mutli valued functions is to name the return values:
([ "file": string f, "crc32": int e ]) = do_shady_things();
I don't see how this would improve anything; it's just as lacking in the possibility to provide good typing, and it's even more inefficient, assuming that a mapping would be used as it looks like. Perhaps I'm missing something.
Syntactic and compatibility problems aside, I'd go with something like this:
[string, int] do_shady_things() { return ["foo", 17]; }
... [string s, int e] = do_shady_things();
On the C level, the multiple return values would simply be pushed on the stack and the functions would return the number of pushed values.
/ Martin Stjernholm, Roxen IS