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