Thread overview
Implicit conversion of unique chars[] to string
Mar 22, 2021
Per Nordlöw
Mar 22, 2021
Per Nordlöw
Mar 22, 2021
ag0aep6g
Mar 23, 2021
ag0aep6g
Mar 23, 2021
Per Nordlöw
Mar 23, 2021
Per Nordlöw
March 22, 2021
Am I the only one being annoyed by the fact that

    chainPath(...).array

doesn't implicit convert to string despite the array returned from .array is allocated by the GC.

Yes, I know that I should do

    chainPath(...).array.assumeUnique

but the uniqueness of .array (and in turn implicit conversion to immutable) should be inferred by the compiler.

Inference could happen in the same compiler pass that checks (will infer) scope qualifiers.

Are there plans for making this happen?

Is having a @unique qualifier motivated for the sake of compiler performance to avoid the for need transitive inference across function calls?
March 22, 2021
On Monday, 22 March 2021 at 20:38:36 UTC, Per Nordlöw wrote:
>     chainPath(...).array

To clarify, for instance, given

      string s;
      const(char)[] c;

all the calls

      chainPath(s, s).array
      chainPath(c, c).array
      chainPath(s, c).array
      chainPath(c, s).array

return a value of type const(char)[].
March 22, 2021
On 22.03.21 21:38, Per Nordlöw wrote:
> Am I the only one being annoyed by the fact that
> 
>      chainPath(...).array
> 
> doesn't implicit convert to string despite the array returned from .array is allocated by the GC.

Works for me:

----
import std.array: array;
import std.path: chainPath;
void main()
{
    string chained = chainPath("foo", "bar").array;
}
----

Uniqueness is being inferred based on purity. If it doesn't work for you, then you're probably doing something impure.
March 22, 2021
On 3/22/21 5:58 PM, ag0aep6g wrote:
> On 22.03.21 21:38, Per Nordlöw wrote:
>> Am I the only one being annoyed by the fact that
>>
>>      chainPath(...).array
>>
>> doesn't implicit convert to string despite the array returned from .array is allocated by the GC.
> 
> Works for me:
> 
> ----
> import std.array: array;
> import std.path: chainPath;
> void main()
> {
>      string chained = chainPath("foo", "bar").array;
> }
> ----
> 
> Uniqueness is being inferred based on purity. If it doesn't work for you, then you're probably doing something impure.

He didn't specify clearly on the original post. Yours works because everything is a string.

Try

const(char)[] x = "foo";
string chained = chainPath(x, "bar").array;

Error: cannot implicitly convert expression array(chainPath(x, "bar")) of type const(char)[] to string

And the answer is complex. You can't accept a const range, because they don't work. The only way to have purity infer uniqueness is to accept paramters that the result could not have come from. Usually this means accepting const and returning mutable.

-Steve
March 23, 2021
On 23.03.21 02:07, Steven Schveighoffer wrote:
> const(char)[] x = "foo";
> string chained = chainPath(x, "bar").array;
> 
> Error: cannot implicitly convert expression array(chainPath(x, "bar")) of type const(char)[] to string
> 
> And the answer is complex. You can't accept a const range, because they don't work. The only way to have purity infer uniqueness is to accept paramters that the result could not have come from. Usually this means accepting const and returning mutable.

Ah, right. Purity was a red herring then. If you put a `const(char)[]` in and you get a `const(char)[]` out, then the compiler must assume that it might be the same one.

We could possibly change `.array` to return a `char[]`. Uniqueness would still fail when you pass a `char[]` in, but that could be worked around by adding a const temporary.
March 23, 2021
On Tuesday, 23 March 2021 at 01:07:15 UTC, Steven Schveighoffer wrote:
> const(char)[] x = "foo";
> string chained = chainPath(x, "bar").array;

that calls the template overload

ForeachType!Range[] array(Range)(Range r)
if (isIterable!Range && !isAutodecodableString!Range && !isInfinite!Range)

should be able to implicitly convert to string because the .array expression is inferred `pure`. Or is the compiler pessimistically assuming that the slice returned from the .array call may reside from a reference reachable from the range parameter `r`?

See for instance

@safe pure unittest
{
    import std.path : chainPath;
    import std.array : array;
    const(char)[] x1 = "foo";
    const string x2 = "bar";
    auto y1 = chainPath(x1, x2).array;
    pragma(msg, __FILE__, "(", __LINE__, ",1): Debug: ", typeof(y1));
    auto y2 = chainPath(x2, x1).array;
    pragma(msg, __FILE__, "(", __LINE__, ",1): Debug: ", typeof(y2));
}

printing

/home/per/f.d(8,1): Debug: const(char)[]
/home/per/f.d(10,1): Debug: const(char)[]
March 23, 2021
On Tuesday, 23 March 2021 at 01:07:15 UTC, Steven Schveighoffer wrote:
> And the answer is complex. You can't accept a const range, because they don't work. The only way to have purity infer uniqueness is to accept paramters that the result could not have come from. Usually this means accepting const and returning mutable.

How do we want this to work with and without the presence of `return` qualified parameters?