Recent

Author Topic: Why can't assign to "for..IN" variable?  (Read 8605 times)

Phemtik

  • New Member
  • *
  • Posts: 19
Re: Why can't assign to "for..IN" variable?
« Reply #15 on: June 14, 2018, 01:01:32 pm »
I think there is no index.
I thought, that It would be jumps to the next position in memory by using the size of element.

No index variable necessary.
Intel i7-3610QM
Fedora 28

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11384
  • FPC developer.
Re: Why can't assign to "for..IN" variable?
« Reply #16 on: June 14, 2018, 01:10:19 pm »

it is more something like an iterator while

Code: Pascal  [Select][+][-]
  1. it:=object.getinterface;
  2. while it.interateover do
  3.   begin
  4.      v:=it.getvalue
  5.      ..... your code here
  6.   end;
   

kupferstecher

  • Hero Member
  • *****
  • Posts: 583
Re: Why can't assign to "for..IN" variable?
« Reply #17 on: June 14, 2018, 04:54:06 pm »
And with modfied variable it could look like that.

Code: Pascal  [Select][+][-]
  1. it:=object.getinterface;
  2. while it.interateover do
  3.   begin
  4.      v:=it.getvalue
  5.      ..... your code here
  6.  
  7.      it.returnvalue(v);
  8.   end;

Still, the iteration isn't disturbed by that (@Thaddy).

ASerge

  • Hero Member
  • *****
  • Posts: 2223
Re: Why can't assign to "for..IN" variable?
« Reply #18 on: June 14, 2018, 07:11:13 pm »
Code: Pascal  [Select][+][-]
  1. var
  2.   vector: array of double;
  3. begin
  4.    FillChar(@vector[Low(vector)], High(vector)-low(vector),0)
  5. end;
  6.  
Code: Pascal  [Select][+][-]
  1.   FillChar(Pointer(vector)^, Length(vector) * SizeOf(vector[Low(vector)]), 0)

Leledumbo

  • Hero Member
  • *****
  • Posts: 8747
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: Why can't assign to "for..IN" variable?
« Reply #19 on: June 15, 2018, 01:08:00 pm »
This is quite interesting, I never imagine such a usecase. I can't imagine the required changes, though. Would it be safe to just change the interface to return a reference, considering it was already illegal to change the loop variable (but AFAIK you can turn that off?). Or a new syntax should be provided? i.e.:
Code: Pascal  [Select][+][-]
  1. for var e in a do ...
using the same semantic for var parameters. Probably the latter is required since built-in iterators aren't user modifiable.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5448
  • Compiler Developer
Re: Why can't assign to "for..IN" variable?
« Reply #20 on: June 15, 2018, 03:30:56 pm »
I don't know how complicated it would be either.

But while I usually think most proposed extensions are mindless bulletlist hunting and syntax grafiti, I think this one would actually be useful. (depending on the work of course).
Actually this used to work in trunk for some time. I think changing members of a record or class is OK, but not the record or class itself. Simple types should be left alone at all.
For in do syntax almost requires that the actual value member can not be changed. I see no reason why the members of a value member can not be changed.

Records are not allowed for modification either (because they'd simply be a copy of the record, thus the changes wouldn't be visible), but classes will work as will dynamic arrays (just to avoid a misunderstanding: if we're iterating through an array of array of something with an array of something as iterator), because those are implicit pointer types and thus you're modifying the content these pointers point to.

Thaddy

  • Hero Member
  • *****
  • Posts: 14214
  • Probably until I exterminate Putin.
Re: Why can't assign to "for..IN" variable?
« Reply #21 on: June 15, 2018, 04:51:10 pm »
@Thaddy
I guess the internal index is always an integer looping type from 0 to high, isn't? The index itself is already hidden by the for..in syntax (no variable exposed to the code), so it would be save to modify the iteration variable.
Yes, correct. The members of any structure should be modifiable. Just not the location. Because that is unknown.
When (not if) you are assuming is is a sequential sequence you are wrong. That's compiler internals.
« Last Edit: June 15, 2018, 04:54:46 pm by Thaddy »
Specialize a type, not a var.

kupferstecher

  • Hero Member
  • *****
  • Posts: 583
Re: Why can't assign to "for..IN" variable?
« Reply #22 on: June 15, 2018, 07:23:09 pm »
Code: Pascal  [Select][+][-]
  1. for var e in a do ...
Thats an interesting idea. It would prevent unintended changes. But on the negative side it makes the syntax more complicated, its not intuitive.

I don't see high risk for unintended value changes anyways, because if you assign a value than normally you actually want to change it. Or in other words, outside a for..in loop you aren't protected for unintended assignments as well, so why here.

Thaddy

  • Hero Member
  • *****
  • Posts: 14214
  • Probably until I exterminate Putin.
Re: Why can't assign to "for..IN" variable?
« Reply #23 on: June 15, 2018, 09:03:34 pm »
The memory manager? I rest my plea...(the memory manager is fine but not for border cases)
You should learn the internals. That goes for any language.
« Last Edit: June 15, 2018, 09:05:38 pm by Thaddy »
Specialize a type, not a var.

kupferstecher

  • Hero Member
  • *****
  • Posts: 583
Re: Why can't assign to "for..IN" variable?
« Reply #24 on: June 15, 2018, 09:48:28 pm »
Do we talk about different things?

If I have a loop like that (if it would/will be possible):

Code: Pascal  [Select][+][-]
  1. setlength(bmpArray,10);
  2. for bmp in bmpArray
  3. do bmp:= TBitmap.Create;
Then I change the address of the class instance. But for the loop that shouldn't be an issue, as the pointer to the class for the loop organization is just data. If this is an integer or pointer or anything else doesn't matter for the loop. As long as I don't touch the array's addresses. So in the example the bmpArray shall be untouched within the loop (like the iteration variable in a normal for..to loop).

 

TinyPortal © 2005-2018