<div dir="ltr"><div>Hi all,<br><br>I want to clarify what <b>feature will be optional</b> and will not break compatibility. I suppose what back compatibility is required for all minor changes. <i>I was thinking it's always by default :)</i><br>
<br><b>Michael Van Canneyt</b>,<br><br>> FPC is not the playground for every possible idea out there.<br>> If someone wants to implement some weird syntax: please; use FPC to try and test it, create your dissertation, whatnot.<br>
</div>May be you understood what I'm from university in wrong way. It does <b>not</b> mean what I need to quickly do any changes anywhere. It means what I have resources <i>(time, motivation, direct support of very good programmer) </i>to improve good open project. Work will not have any good value for me if results of work will not have any good value for other people.<br>
<br>> "For in" is debatable by itself. It is syntactical sugar, it provides nothing that for a:=b to c does not give.<br>> Now you propose to extend this "sugar" syntax with something even more exotic, which I have not even encountered in other languages.<br>
<div>1. Syntax is subject of discussion and can be changed.<br></div><div>2. Freepascal already have for-in syntax sugar. Why not to make it more <span class="">flexible?</span><br><br></div><div>Request of this what for-in-index is on fpc wiki. Some other pascal programmers told in this thread what this is good feature.<br>
Evolution of other popular programming languages shows what for-in-index loop have real value <i>(describes by Alexander S. Klenin)</i>.<br></div><div>Implementation of  for-in-index will be basad on existing for-in loop. Thus feature will have almost same behavior as for-in loop. All implementation problems described in this thread relate to existing for-in loop. They are not relevant to discussion of for-in-index loop.<br>
<br></div><div>I understand why you don't want to support bad features. But I don't understand why reasonable extension of existing feature (which will not break compatibility and which exists in other languages) is bad ? :)<br>
</div><div><br></div><div></div><div></div><div>Best regards,<br></div><div>Vasiliy Kevroletin<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/1/25 Paul Ishenin <span dir="ltr"><<a href="mailto:ip@kmiac.ru" target="_blank">ip@kmiac.ru</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">25.01.2013 4:32, Alexander Klenin пишет:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Jan 25, 2013 at 7:18 AM, Jeppe Græsdal Johansen<br>
<<a href="mailto:jjohan07@student.aau.dk" target="_blank">jjohan07@student.aau.dk</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think the idea is good if the feature is implemented as "optional".<br>
<br>
That way:<br>
- If the enumerator class implements a CurrentIndex method then the for loop<br>
can have an index variable.<br>
- If not then the for loop can only behave as current for in loops.<br>
<br>
</blockquote>
Of course.<br>
</blockquote>
<br></div>
Then I also have nothing against this feature. If it is controllable by enumrator to allow/reject this then it is ok.<br>
<br>
Best regards,<br>
Paul Ishenin<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
fpc-devel maillist  -  <a href="mailto:fpc-devel@lists.freepascal.org" target="_blank">fpc-devel@lists.freepascal.org</a><br>
<a href="http://lists.freepascal.org/mailman/listinfo/fpc-devel" target="_blank">http://lists.freepascal.org/<u></u>mailman/listinfo/fpc-devel</a><br>
</div></div></blockquote></div><br></div>