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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
