[fpc-devel] RFC: Support for new type "tuple" v0.1

[Jonas Maebe]

On 26 Jan 2013, at 21:45, Alexander Klenin wrote:

> 2.2.2) Any record or array type may be converted to a tuple of its
> elements using either assignment or "Tuple" intrinsic.
> For example: Tuple(ARectangle) is a tuple of 4 elements;
> x, y := APoint; // same as x := APoint.x; y := APoint.y;
[snip]
> 2.3.2) When tuple appears inside of a function/procedure argument, it
> is deconstructed, and its elements are passed as a separate arguments.
>  Tuple elements corresponding to var, out and constref parameters
> must be lvalues. Note that due to (2.2.2) tuple may represent only
> part of arguments.
>  Together with (2.2) we note that normal semantics of procedure
> parameters is left unchanged :)
>  We also gain this:
> 
> procedure SomeLibrary.DrawLine(X1, Y1, X2, Y2, Color: Integer); //
> Author did forgot/did not want to declare overload with "TRect"
> parameter.
> ...
> DrawLine(Tuple(ClientRect), clRed); // No need, tuples help here

I don't like these automatic conversions/deconstructions of records at all, nor the ability to have the compiler automatically convert a tuple to its component elements when resolving function calls. It means that you no longer have a tuple type, but rather a deconstruct_into_component_types() type conversion operator along with anonymous records. The fact that the tuple() operator is required when deconstructing a record when calling a function (as in 2.3.2) while it is not when assigning a record to multiple values (as in 2.2.2) shows that such automatic conversions are not a good idea. Implicitly applying it in one case and not in another is not good, and I'm definitely against automatically converting records into its component elements for passing as parameters.

A tuple should either be a real type with fixed type conversion semantics that behave the same in every situation (like other types, and like how Pascal usually works: context-insensitive evaluation of expressions), or not exist at all (and this option is certainly fine with me as well). And another option is indeed extending the syntax of the for-statement, although there of course also downsides to do doing that. However, new magic operators that have their own rules are what really complicates a language, both in the compiler implementation and for people that have to use it.


Jonas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20130127/5a3e0953/attachment.html>