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

[d-bugmail--- via Digitalmars-d-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P2  |P4

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #36 from Dlang Bot  ---
@nordlow updated dlang/dmd pull request #12341 "Fix 1654 - Array concatenation
result should be implicitly castable between mutable and immutable if the
elements support it." fixing this issue:

- Fix 1654 - Array concatenation result should be implicitly castable between
mutable and immutable if the elements support it.

https://github.com/dlang/dmd/pull/12341

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #35 from Mathias LANG  ---
*** Issue 12402 has been marked as a duplicate of this issue. ***

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

Bolpat  changed:

   What|Removed |Added

 CC||qs.il.paperi...@gmail.com

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

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

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

Simen Kjaeraas  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||simen.kja...@gmail.com
 Resolution|WORKSFORME  |---

--- Comment #33 from Simen Kjaeraas  ---
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.

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

RazvanN  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |WORKSFORME

--- Comment #32 from RazvanN  ---
This code:

char *toStringz2(const(char)[] s)
{
return (s ~ "\0").ptr;
}

compiles successfully today, so I am going to mark this one as WORKSFORME.

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

Summary|Array concatenation should  |Array concatenation result
   |result in mutable or|should be implicitly
   |invariant depending on  |castable between mutable
   |usage   |and immutable if the
   ||elements support it.

--