[Issue 1654] Array concatenation result should be implicitly castable between mutable and immutable if the elements support it.

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=1654

--- Comment #34 from Steven Schveighoffer <schveiguy at yahoo.com> ---
(In reply to RazvanN from comment #32)
> This code:
> 
> char *toStringz2(const(char)[] s)
> {
>     return (s ~ "\0").ptr;
> }
> 
> compiles successfully today, so I am going to mark this one as WORKSFORME.

This is nice, is this a recent change? In any case, I think it would be nice if
we simply consider the result equivalent to a pure function:

T[] concat(T)(const(T[]) arr1, const(T[]) arr2) pure

for T that have no indirections. This should solve the problem. But I can't say
that it's necessary much any more, we have so many new tools since 2007/2008.

(In reply to Simen Kjaeraas from comment #33)
> So no, this is not fixed. When it's fixed, all of the above should compile
> without issue.

I tried out a simple function prototyped as above, it works, except for the
automatic casting of the .ptr property: https://run.dlang.io/is/Bu3k1G

And I actually think it's fine for the .ptr inference to fail. Simply because
by the time we get to the .ptr property, the compiler has to have decided what
type the array return is, and it defaults to mutable.

But in any case, we have some "new" information, especially around the
pure/unique situation which shows this is reasonable and possible. I don't know
still if it's worth pursuing this enhancement request. The only thing I would
say would be nicer is if we could somehow specify a *unique* array vs. just a
mutable one. Because things like:

auto x = str ~ "";

causing x to be char[] and not string could cause bad problems. It would be
nice if the result *defaulted* to something based on the arguments but allowed
implicit casting if necessary because of the uniqueness.

--