Function returning multiple values

Community Forums/Monkey2 Talk/Function returning multiple values

JoshKlint(Posted 2015) [#1]
It's not really high priority, but one feature to consider might be returning multiple values from a function like Lua does:
Local x:Int, y:Int

x,y = GetDrawingPosition()


I've noticed a lot of BMX functions that accept pointers to variables because they need to return multiple values. This would be a way to handle that a bit better.

Also maybe consider the shortcut @ to replace var ptr:
Local x:Int=1,y:Int=2
memcopy @x, @y, sizeof(x)


This is something PureBasic does, and I find it intuitive.


Danilo(Posted 2015) [#2]
@ (At) in PureBasic gives the address of variables, functions, strings, arrays, ...
*pointer1 = @variable
*pointer2 = @"this is a string"
*pointer3 = @myFunction()
*pointer4 = @myArray()
*pointer5 = @myArray(12,12)     ' address of array field
*pointer6 = @myStructure\member ' address of structured variable member

Define pt.POINT   ' POINT structure
*pointer7 = @pt\x ' address of pt \ x
*pointer8 = @pt\y ' address of pt \ y

It's like '&' in C/C++.


Nobuyuki(Posted 2015) [#3]
If we're using pointers in mx2, then a sigil might be useful. I don't think either of these things are particularly basic-like, though.

How does a lua function return multiple values? I'm used to languages that don't rely on you explicitly using and assigning pointers. Data transport objects increase encapsulation /safety...


marksibly(Posted 2015) [#4]
Tuples would be nice, but they're a big change that affect a lot of things. So they probably wont happen in the near future, but I am keeping in mind how they could work syntactically.

Varptr will stay, 'coz it's ugly and so are pointers. Pointer code is unsafe, and I prefer it to look that way! I'd also like to reserve '@' for possible future use.

Ideally, it'd be nice if pointers only appeared in lib interface code, along with externs and stub functions that 'sanitise' them and deal with gc issues etc. This is how I'm going to approach module development anyway.


JoshKlint(Posted 2015) [#5]
I can understand the reason for that. Heisenbergs are the absolute worst.


Samah(Posted 2015) [#6]
@marksibly: Varptr will stay, 'coz it's ugly and so are pointers.

And because it's the same as BlitzMax syntax. :)

It'd be nice to be able to use ref variables like in C#. The int.TryParse method is a good example, because it both parses the value and gives you a success boolean.


marksibly(Posted 2015) [#7]
BlitzMax had 'Var' for function params only - be quite nice to resurrect.