import std.algorithm: map; import std.array: array; struct Foo { immutable dchar d; } struct Bar { immutable int x; } void main() { "12".map!Foo.array; [1, 2].map!Bar.array; } DMD 2.064alpha gives: ...\dmd2\src\phobos\std\array.d(2309): Error: cannot modify struct delegate Foo[]() { return (cast(Foo*)(*this._data).arr)[len..len + 1u]; } ()[0u] Foo with immutable members ...\dmd2\src\phobos\std\array.d(69): Error: template instance std.array.Appender!(Foo[]).Appender.put!(Foo) error instantiating temp.d(10): instantiated from here: array!(MapResult!(Foo, string)) temp.d(10): Error: template instance std.array.array!(MapResult!(Foo, string)) error instantiating ...\dmd2\src\phobos\std\array.d(58): Error: cannot modify struct result[i] Bar with immutable members temp.d(11): Error: template instance std.array.array!(MapResult!(Bar, int[])) error instantiating
(In reply to comment #0) > import std.algorithm: map; > import std.array: array; > struct Foo { > immutable dchar d; > } > struct Bar { > immutable int x; > } > void main() { > "12".map!Foo.array; > [1, 2].map!Bar.array; > } > > > > DMD 2.064alpha gives: > > ...\dmd2\src\phobos\std\array.d(2309): Error: cannot modify struct delegate > Foo[]() > > { > > return (cast(Foo*)(*this._data).arr)[len..len + 1u]; > > } > > ()[0u] Foo with immutable members > ...\dmd2\src\phobos\std\array.d(69): Error: template instance > std.array.Appender!(Foo[]).Appender.put!(Foo) error instantiating > temp.d(10): instantiated from here: array!(MapResult!(Foo, string)) > temp.d(10): Error: template instance std.array.array!(MapResult!(Foo, string)) > error instantiating > ...\dmd2\src\phobos\std\array.d(58): Error: cannot modify struct result[i] Bar > with immutable members > temp.d(11): Error: template instance std.array.array!(MapResult!(Bar, int[])) > error instantiating This is an interesting scenario, as it reveals bugs in several steps of the "tool chain". In regards to "Bar", the first bug is in "std.array.array", and will soon be fixed. Unfortunately, it will pass through std.conv.emplace, which is not fixed, so it will stop working there. I have an open pull for fixing said conv, but I'm unsure it handles this scenario (I'm pretty confident it actually *doesn't*). I'll double check, but I don't think I'll make any changes to it to support this scenario, I'd rather make slow but confirmed steps to improving emplace. Still, this is an interesting bug. I'll check back to it often.
*** This issue has been marked as a duplicate of issue 9528 ***