https://issues.dlang.org/show_bug.cgi?id=1654
--- Comment #34 from Steven Schveighoffer <schvei...@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. --