foreach() behavior on ranges

Ferhat Kurtulmuş aferust at gmail.com
Tue Aug 24 20:44:59 UTC 2021


On Tuesday, 24 August 2021 at 19:06:44 UTC, Alexandru Ermicioi 
wrote:
> On Tuesday, 24 August 2021 at 09:15:23 UTC, bauss wrote:
>> [...]
>
> Actually the range contracts don't mention that it needs to be 
> a by value type. It can also be a reference type, i.e. a class.
>
>> [...]
>
> True for any forward range and above, not true for input 
> ranges. The problem with them is that some of them are structs, 
> and even if they are not forward ranges they do have this 
> behavior due to implicit copy on assignment, which can 
> potentially make the code confusing.
>
>> [...]
>
> If we follow the definition of ranges, they must not be 
> copy-able at all. The only way to copy/save, would be to have 
> .save method and call that method. This again is not being 
> properly followed by even phobos implementations.
>
> Note, that a better approach would be to replace .save in 
> definition of forward range with a copy constructor, then all 
> non-compliant ranges would become suddenly compliant, while 
> those that have .save method should be refactored to a copy 
> constructor version.
>
>> [...]
>
> You should add .save on assignment if range is a forward range, 
> or just remove the assignment if it is not.
>
> Best regards,
> Alexandru.

Just out of curiosity, if a range implementation uses malloc in 
save, is it only possible to free the memory with the dtor? I 
worry about that especially when using those nogc range 
implementations with standard library. I don't have a list of the 
functions calling save in phobos. Is a save function only 
meaningful for GC ranges?


More information about the Digitalmars-d-learn mailing list