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

[Alexander Klenin]

On Mon, Jan 28, 2013 at 2:59 AM, Michael Van Canneyt
<michael at freepascal.org> wrote:
>
>
> On Mon, 28 Jan 2013, Alexander Klenin wrote:
>> I have a compromise suggestion:
>> Implement for-index extension with the syntax:
>> for (k, v) in a do
>> this syntax is forward-compatible with both tuples proposals,
>> is simple to do (basically, already done -- only a small change in
>> parsing is required)
>
> what concerns syntax, I have no problem with this.
>
> What bothers me immensely is the same what bothered me in the totally
> braindead
> Delphi implementation of the "for in" loop : the bunch of requirements you
> put on the iterator implementation: an interface with special status. You
> can't get more stupid and ugly than that.
Out of curiosity -- how would you implement it?
(Except "the Oberon way" -- by telling the programmer that he is
better off without this feature :-))

I have no particular like or dislike for the Delphi's enumerable implementation,
but it is quite similar to for-in iterators in most other compiled languages.

> Your initial proposal makes it even worse by adding more conditions to the
> interface, it would not even be an interface any more.
I am not sure what are you talking about. Interface is a list of methods.
My for-in proposal would add a new interface (with a single method)
which, if supported by enumerator, would allow user to write for-in-index loops.

> That is why I think you need a proper "tuple" value to solve this.
> it gives a more fundamental solution: the loop variable type equals the type
> returned by the iterator/enumerator. No messing with index (bad syntax) and
> even worse: special 'interfaces' and whatnot.
I agree that "index" keyword was perhaps not optimal choice.
New interface is needed anyway to preserve backwards compatibility
(and efficiency for the case when the key is not needed).
"Do not slow down existing code".

> Pascal is a strongly typed language. So, if we absolutely must solve this:
> introduce a proper type. A tuple fits the job.
So does the record -- tuple is needed here only to deconstruct that
record in separate variables.

--
Alexander S. Klenin