Somewhat related to

https://github.com/D-Programming-Language/phobos/pull/2024

I wonder about the soundness of `map` in


```D
import std.algorithm, std.range, std.stdio;
void main(string[] args)
{
      long[] arr;
      const n = 3;
      iota(n).map!(a => arr ~= a);
      writeln(arr);
      writeln(iota(n).map!(a => arr ~= a));
      writeln(arr);
}
```

that prints

```D
[]
[[0], [0, 1], [0, 1, 2]]
[0, 1, 2]
```

Shouldn't a warning at least be issued for return-ignoring calls
to map with mutating lambdas? Has there been any discussions on
making map require pure functions now that we have each? I guess
a new function, say `mapPure`, may be neccessary as adding such a
restriction to the lambda will break too much code right?

Nordlöw:

> Has there been any discussions on
> making map require pure functions now that we have each?

Perhaps I'd like Phobos map and filter to be annotated with "pure" and to have a template constraint that requires their mapping/filtering functions to be strongly pure.

Bye,
bearophile

On Tuesday, 13 January 2015 at 10:06:26 UTC, bearophile wrote:
> Nordlöw:
>
>> Has there been any discussions on
>> making map require pure functions now that we have each?
>
> Perhaps I'd like Phobos map and filter to be annotated with "pure" and to have a template constraint that requires their mapping/filtering functions to be strongly pure.
>
> Bye,
> bearophile

Please not.

On Tuesday, 13 January 2015 at 10:21:12 UTC, Tobias Pankrath wrote:
> On Tuesday, 13 January 2015 at 10:06:26 UTC, bearophile wrote:
>> Nordlöw:
>>
>>> Has there been any discussions on
>>> making map require pure functions now that we have each?
>>
>> Perhaps I'd like Phobos map and filter to be annotated with "pure" and to have a template constraint that requires their mapping/filtering functions to be strongly pure.
>>
>> Bye,
>> bearophile
>
> Please not.

It should be obviously documented that the number of applications of the function is not limited to once-per-element and that evaluation doesn't necessarily happen in-order. I forget and am re-reminded of this once every few months, despite how central it is to ranges in general.

It can still be useful to use impure functions with it though, as long as you consider what is actually going on.

On Tue, 13 Jan 2015 10:06:25 +0000
bearophile via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> Nordlöw:
> 
> > Has there been any discussions on
> > making map require pure functions now that we have each?
> 
> Perhaps I'd like Phobos map and filter to be annotated with "pure" and to have a template constraint that requires their mapping/filtering functions to be strongly pure.

that will effectively rule out any usage of some global vars or other external state, turning it into either unnecessary mess, or unusable theoretical crap.

what i think should be written in big red letters in docs is "there is no guarantees about how many times labmda will be called, with which args and in which order". so if someone wants to shoot in his foot, he can ignore that warning and do crazy shooting.

ketmar:

> that will effectively rule out any usage of some global vars or other
> external state, turning it into either unnecessary mess, or unusable
> theoretical crap.

"Unusable theoretical crap" is better than the current trap :-)

We hare "pure" in D, but still we have not grown up to actually use it in Phobos, for higher order functions, or parallelism.

Bye,
bearophile

> "Unusable theoretical crap" is better than the current trap :-)
>
> We hare "pure" in D, but still we have not grown up to actually use it in Phobos, for higher order functions, or parallelism.

I don't think that Nordlöw presented a serious trap. This might lead to bugs, yes, like anything else, for example: void foo(int[] arr) { ... arr ~= ... }

Same error, if you expect arr to be changed outside the function. In the case of Nordlöw: If you add a warning* it will issue many warnings for a huge amount of perfectly fine code making the warning useless. Forbidding it, would be even worse (since the code wouldn't work, a more verbose alternative needs to be used etc ..). For what? To prevent a possible bug that is easily found and fixed? Wrong trade-off if you ask me.


* When should the warning actually be issued? Whenever a closure is passed to map? Whenever a closure passed to map closes over something where hasAliasing!T is true?

On Tue, 13 Jan 2015 11:26:01 +0000
bearophile via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> ketmar:
> 
> > that will effectively rule out any usage of some global vars or
> > other
> > external state, turning it into either unnecessary mess, or
> > unusable
> > theoretical crap.
> 
> "Unusable theoretical crap" is better than the current trap :-)
in no way. this just turns Phobos into the same unusable crap, removing the whole sense of having good standard library.

> We hare "pure" in D, but still we have not grown up to actually use it in Phobos, for higher order functions, or parallelism.
let an user choose if he wants pure or impure HOF args. just make a big warning in documentation about unpredictability of HOFs with side-effects and this will be enough, i believe.

ketmar:

> in no way. this just turns Phobos into the same unusable crap, removing the whole sense of having good standard library.

If your language has purity, and it doesn't use it where it matters, you have removed its sense of having purity. So if you are right then purity in D is useless and Rust has chosen better than D on this.

Bye,
bearophile

On Tuesday, 13 January 2015 at 07:35:53 UTC, Nordlöw wrote:
> Somewhat related to
>
> https://github.com/D-Programming-Language/phobos/pull/2024
>
> I wonder about the soundness of `map` in
>
>
> ```D
> import std.algorithm, std.range, std.stdio;
> void main(string[] args)
> {
>       long[] arr;
>       const n = 3;
>       iota(n).map!(a => arr ~= a);
>       writeln(arr);
>       writeln(iota(n).map!(a => arr ~= a));
>       writeln(arr);
> }
> ```
>
> that prints
>
> ```D
> []
> [[0], [0, 1], [0, 1, 2]]
> [0, 1, 2]
> ```
>
> Shouldn't a warning at least be issued for return-ignoring calls
> to map with mutating lambdas? Has there been any discussions on
> making map require pure functions now that we have each? I guess
> a new function, say `mapPure`, may be neccessary as adding such a
> restriction to the lambda will break too much code right?

To clarify:

I f() is stronly pure function then DMD since 2.066 will warn about

   f();

, that is, upon return-discarding calls to strongly pure function.

I believe

    iota(n).map!(a => arr ~= a);

is a very similar mistake done and if possible should be warned about.

Is it possible to
- detect that a lambda is has-side-effects and that
- the map hasn't been used?

If this can't (yet) be detected in compiled-time what about issuing an exception in the destructor of Map to detect this?

Destroy!