in the way of changing my code to use table lookups i wrote this:

private immutable bool[256] cc_specialChars =
  iota(0, 0x100)
  .map!(i => i <= 32 || i == '"' || i == '\\' || i == ';' || i == '#' || i == 127)
  .array;

and got compilation error: function iv.cmdcon.__lambda34!int.__lambda34 is not accessible from module algorithm.

i perfectly understand why compiler complains, but i think that this restriction can be weakened a little for modules, imported as 'private import modname'. i.e. if  importing like this:

private import std.algorithm;

std.algorithm should have full acces to private vars from the current module. this will not break existing code (i think) and will allow to avoid copypasting.

On Wednesday, 2 April 2014 at 08:49:52 UTC, ketmar wrote:
> in the way of changing my code to use table lookups i wrote this:
>
> private immutable bool[256] cc_specialChars =
>   iota(0, 0x100)
>   .map!(i => i <= 32 || i == '"' || i == '\\' || i == ';' || i == '#' || i == 127)
>   .array;
>
> and got compilation error: function iv.cmdcon.__lambda34!int.__lambda34 is not accessible from module algorithm.
>
> i perfectly understand why compiler complains, but i think that this restriction can be weakened a little for modules, imported as 'private import modname'. i.e. if  importing like this:
>
> private import std.algorithm;
>
> std.algorithm should have full acces to private vars from the current module. this will not break existing code (i think) and will allow to avoid copypasting.

Isn't the problem here that the compiler is mistakenly making the the lambda private? I don't think it should be.

John Colvin:

> Isn't the problem here that the compiler is mistakenly making the the lambda private? I don't think it should be.

https://d.puremagic.com/issues/show_bug.cgi?id=12506

(But the issue name is not very good).

Bye,
bearophile

tnx. i'm not that good in inventing good descriptive names for bug reports, so i appreciate your help here: it's way better than the one i can think out by myself. ;-)