[Issue 1654] Array concatenation should result in mutable or invariant depending on usage

Nov 01, 2014

Marc Schütz

Nov 01, 2014

Jan 10, 2015

Feb 28, 2018

Feb 28, 2018

Mar 01, 2018

https://issues.dlang.org/show_bug.cgi?id=1654 Marc Schütz <schuetzm@gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schuetzm@gmx.net --

https://issues.dlang.org/show_bug.cgi?id=1654 Sobirari Muhomori <dfj1esp02@sneakemail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://issues.dlang.org/sh | |ow_bug.cgi?id=13488 --

https://issues.dlang.org/show_bug.cgi?id=1654 Ivan Timokhin <timokhin.iv@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |timokhin.iv@gmail.com --

https://issues.dlang.org/show_bug.cgi?id=1654 Steven Schveighoffer <schveiguy@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #29 from Steven Schveighoffer <schveiguy@yahoo.com> --- This is a really old one. Going to close, since I think we have ways around this (i.e. pure functions returning unique data). --

https://issues.dlang.org/show_bug.cgi?id=1654 timon.gehr@gmx.ch changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX |--- Severity|major |enhancement --- Comment #30 from timon.gehr@gmx.ch --- I don't understand why you wanted to close this issue. Anyway, there are two duplicates, so I'll reopen it. --

https://issues.dlang.org/show_bug.cgi?id=1654 --- Comment #31 from Steven Schveighoffer <schveiguy@yahoo.com> --- I expect at some point for concatenation to be a fully lowered template function, and at that point, we have all the tools to do this. You can leave it open if you want, I was just looking through issues I had reported, and this one just struck me as being very stale, not just in time but in light of all the developments that have happened in D since 2007. --

https://issues.dlang.org/show_bug.cgi?id=1654 RazvanN <razvan.nitu1305@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED CC| |razvan.nitu1305@gmail.com Resolution|--- |WORKSFORME --- Comment #32 from RazvanN <razvan.nitu1305@gmail.com> --- This code: char *toStringz2(const(char)[] s) { return (s ~ "\0").ptr; } compiles successfully today, so I am going to mark this one as WORKSFORME. --

https://issues.dlang.org/show_bug.cgi?id=1654 Simen Kjaeraas <simen.kjaras@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |simen.kjaras@gmail.com Resolution|WORKSFORME |--- --- Comment #33 from Simen Kjaeraas <simen.kjaras@gmail.com> --- It works for string literals, but not for two variables: unittest { import std.meta : AliasSeq; static foreach (T; AliasSeq!(char, const(char), immutable(char))) {{ pragma(msg, T.stringof, ":"); T[] s = "".dup; // Result type of concatenation may differ: pragma(msg, "Variable: ", typeof(s~s).stringof); pragma(msg, "Literal: ", typeof(s~"").stringof); // Two const(char)[]s: { char* p1 = (s~s).ptr; immutable(char)* p2 = (s~s).ptr; const(char)* p3 = (s~s).ptr; char[] a = s~s; string b = s~s; const(char)[] c = s~s; } // One literal: { char* p1 = (s~"").ptr; immutable(char)* p2 = (s~"").ptr; const(char)* p3 = (s~"").ptr; char[] a = s~""; string b = s~""; const(char)[] c = s~""; } }} } So no, this is not fixed. When it's fixed, all of the above should compile without issue. --

August 28, 2019

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

Posted by Steven Schveighoffer

Permalink

Steven Schveighoffer

Permalink

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

--- Comment #34 from Steven Schveighoffer <schveiguy@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.

--

Forums