I think a better approach would be to add a Tuple class to Xojo using Auto elements, and support tuple unpacking on assignment, much like Python does it. Multiple return values are quite handy in some situations.
Return a simple class you have made with a Constructor( ) that you give the parameters to which it will store in properties and return trough computed property āgetā.
Dictionary is an option too or an Array as said above.
C#, C++, Java and many other languages do not support multiple return values
In Xojo multiple return values is unlikely to happen - its such a large change to the language
So
- use a class
- use an array/dictionary/pairs
- byref
I believe that Tuples will be the next level of the current Xojo Pair.
aPair = (1 : ā2ā)
aTuple = (one : 2 : ā3ā)
(x : y : z) = (1 : 2 : 3) // Multi assignment
Function getXYZ() As Tuple
Return (1 : 2 : 3)
End Function
(x : y : z) = getXYZ()
http://openbookproject.net/thinkcs/python/english3e/tuples.html
you can already do āa:b:cā where [a] is left of a pair, and [b:c] is another pair that is the right of the first pair
Iāve done this beforeā¦ but it has been a long time
[quote=199939:@Dave S]you can already do āa:b:cā where [a] is left of a pair, and [b:c] is another pair that is the right of the first pair
Iāve done this beforeā¦ but it has been a long time[/quote]
I looked at pairs linked lists. Difficult to conceive worseā¦
Iāll rather use a class, a dictionary or an arrayā¦
I would prefer it firing a warning/Error in new compilers. This construct should be (a: (b : c)) in a Tuple construct.
I still prefer the proper modern constructs. At some point in time Xojo will need to introduce it, so itās good to discuss earlier just to have it in mind.
Lets just say my money is on āUnlikelyā
My money will be on āmodernize or dieā. Letās wait. 
C#, Java ,ad C++ all get along fine without
Multiple return values isnāt āmore modernā or āless modernā - just different
*FYI - Iān going with what the compiler guys have all said over the the last 10+ years
Tell that to all the guys still using COBOL, FORTRAN and PIC.
All them have it (some are not so good implementations). C++ TR1+, C# 4.0+, and SPAR Java (and Why Tuples for compiler guys).
Some old and most of the new languages implements Tuples (some better than others) like:
Prolog, OCaml, Scala, D, Erlang, Haskell, Python, C#, F#, Rust, SwiftĀ
Hey, I am one of those guys too (not PIC, never heard of). And those languages are at the level of ākind of dyingā. We already have COBOL to Java source code translator programs. Haskell maybe have more users than the sum of COBOL and FORTRAN users worldwide right now.
Well, we already discussed. Lets just wait and see future options, going towards Python, Rust, Swift or COBOL, FORTRAN, PIC.
I wouldnt think this would be so difficult to implement.
I dont know how youāre dealing with that Norman, but I think to a kind of preprocess thing
that transform
(value1,..,valuen) = mymethod( param1,..,paramn)into
mymethod( param1,..,paramn,byref value1,..byref valuen)before the compiling process, and then the compile process is the same
is it also not feasible relatively easy ?
[quote=200000:@Norman Palardy]C#, Java ,ad C++ all get along fine without
Multiple return values isnāt āmore modernā or āless modernā - just different
*FYI - Iān going with what the compiler guys have all said over the the last 10+ years :)[/quote]
While sensibly having only one return value for functions, even C allows this functionality; you simply pass arguments by reference. This is the way this functionality is implemented in many languages.
On the whole though, If I wanted a bunch of return values, a class would be the most appropriate solution, followed by an array or whatever in memory structure worked best.
That is exactly what was mentioned above, but it does not seem to be enough to some 
I for one am not an āugly workaround loverā. I believe everybody here knows that. Why not throw away pairs from the language too! Everybody should just implement their own solutions using terrible āarguments and referenceā workarounds. Seems the way to go.
I would not expect to see pairs make it into the new framework.
[quote=200046:@jean-yves pochez]I wouldnt think this would be so difficult to implement.
I dont know how youāre dealing with that Norman, but I think to a kind of preprocess thing
that transform
(value1,..,valuen) = mymethod( param1,..,paramn)into
mymethod( param1,..,paramn,byref value1,..byref valuen)before the compiling process, and then the compile process is the same
is it also not feasible relatively easy ?[/quote]
Not so simple
Suppose you have method āFooā that returns 3 values
But when you call it you only use 2
What youāre suggesting would REQUIRE you to ALWAYS use all three (otherwise the rewrite to byref wont work without additional code changes in the method called)
You might as well use byref & write your code that way
Tuple returns are certainly already possible - create a Tuple class (wrap a dictionary) and provide an operator_lookup on it and you can probably get a lot of the āmultiple return valuesā feature you want with no changes in the compiler & its fully in your control
I would not hold my breath waiting for this to arrive in Xojo
ok. thanks for taking time to answer my request.
macoslib has a tuple class (looks to be pure Xojo code so should work cross-platform)