September 09, 2012 Re: Eliminate redundancy of dup/idup | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On 09/09/2012 06:32 PM, Timon Gehr wrote:
> On 09/09/2012 05:32 PM, kenji hara wrote:
>> ...
>> Then the elements of returned value keep original type modifier.
>> ...
>
> Usually .dup or .idup are used to explicitly change the type modifier,
> and they still allow type deduction.
> I'd be fine with having .dup be inout, .mdup mutable and .idup
> immutable.
Ignore that, I misunderstood.
|
September 09, 2012 Re: Eliminate redundancy of dup/idup | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | Timon Gehr wrote:
> -1 for removing .idup, it is handy.
auto idup(E)(const(E)[] arr) pure @trusted
{
immutable result = arr.dup();
return result;
}
:-)
|
September 09, 2012 Re: Eliminate redundancy of dup/idup | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On 09/09/2012 06:33 PM, Adam D. Ruppe wrote:
> On Sunday, 9 September 2012 at 16:25:12 UTC, Timon Gehr wrote:
>>>> c = "another"; // so this compiles
>>
>> This does not compile anymore now.
>
>
> One option I've heard that might be OK is to make auto strip off the top
> level immutable:
>
> immutable(char[]) a;
> auto b = a; // b is immutable(char)[]
> b = "test"; // allowed
>
>
> This kind of thing is already done on function calls.
>
>
> If you want to keep the full immutability including the top one, use
> immutable instead of auto.
I am in favour of this change, but why would it help eliminate the usefulness of .idup?
|
September 09, 2012 Re: Eliminate redundancy of dup/idup | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Sunday, 9 September 2012 at 16:38:43 UTC, Timon Gehr wrote:
> I am in favour of this change, but why would it help eliminate the usefulness of .idup?
I'm not for the removal of idup.
|
September 09, 2012 Re: Eliminate redundancy of dup/idup | ||||
---|---|---|---|---|
| ||||
Posted in reply to Piotr Szturmaj | On 09/09/2012 06:37 PM, Piotr Szturmaj wrote: > Timon Gehr wrote: >> -1 for removing .idup, it is handy. > > auto idup(E)(const(E)[] arr) pure @trusted > { > immutable result = arr.dup(); > return result; > } > auto idup(E)(const(E)[] arr) pure nothrow @safe if(is(typeof({immutable r=arr.dup;}))){ return cast()cast(immutable)arr.dup; } > :-) |
September 09, 2012 Re: Eliminate redundancy of dup/idup | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | An advantage of generic dup() is to allow copying of const arrays.
void main()
{
class C {}
const C[] ca = new C[3];
//ca.dup;
// Error: cannot implicitly convert element type const(C) to
mutable in ca.dup
//ca.idup;
// Error: cannot implicitly convert element type const(C) to
immutable in ca.idup
ca.dup();
// result is const(C[])
}
----
According to what I remember, the name 'idup' had been discussed in the beginning of D2, but it had been disappeared from the need for idup. But it is still oddly name.
Using:
auto iarr = marr.idup;
Instead of :
immutable iarr = marr.dup(); // In the future, () would not be necessary
Is really handy? Yes, it is 6(or 4) characters shorter. But I can't
see it *handy*.
"idup" is still odd name to me.
Kenji Hara
2012/9/10 Timon Gehr <timon.gehr@gmx.ch>:
> On 09/09/2012 05:44 PM, kenji hara wrote:
>>
>> 2012/9/10 Adam D. Ruppe <destructionator@gmail.com>:
>>>
>>> On Sunday, 9 September 2012 at 15:32:01 UTC, kenji hara wrote:
>>>
>>>>
>>>> Then returned value can be implicitly convertible to immutable(E[]).
>>>
>>>
>>>
>>> What about rebindable with auto? For example:
>>>
>>> void main() {
>>> char[] a = "cool".dup;
>>> string b = a.idup; // explicitly immutable(char)[]
>>> auto c = a.idup; // automatically typeof(c) == immutable(char)[]
>>
>>
>> Yes. In this case, you should write:
>> immutable c = a.dup(); // explicit immutable conversion
>>
>>> c = "another"; // so this compiles
>
>
> This does not compile anymore now.
>
>>> }
>
>
> +1 for moving to library and lifting restrictions on conversion. -1 for removing .idup, it is handy.
|
September 09, 2012 Re: Eliminate redundancy of dup/idup | ||||
---|---|---|---|---|
| ||||
Posted in reply to kenji hara | On 09/09/2012 07:06 PM, kenji hara wrote:
> An advantage of generic dup() is to allow copying of const arrays.
>
> void main()
> {
> class C {}
> const C[] ca = new C[3];
> //ca.dup;
> // Error: cannot implicitly convert element type const(C) to
> mutable in ca.dup
> //ca.idup;
> // Error: cannot implicitly convert element type const(C) to
> immutable in ca.idup
> ca.dup();
> // result is const(C[])
> }
>
> ----
>
> According to what I remember, the name 'idup' had been discussed in
> the beginning of D2, but it had been disappeared from the need for
> idup. But it is still oddly name.
>
> Using:
> auto iarr = marr.idup;
> Instead of :
> immutable iarr = marr.dup(); // In the future, () would not be necessary
>
> Is really handy? Yes, it is 6(or 4) characters shorter. But I can't
> see it *handy*.
What you are missing is that the two code segments are not equivalent.
|
September 09, 2012 Re: Eliminate redundancy of dup/idup | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 2012/9/10 Timon Gehr <timon.gehr@gmx.ch>:
> On 09/09/2012 07:06 PM, kenji hara wrote:
>>
>> An advantage of generic dup() is to allow copying of const arrays.
>>
>> void main()
>> {
>> class C {}
>> const C[] ca = new C[3];
>> //ca.dup;
>> // Error: cannot implicitly convert element type const(C) to
>> mutable in ca.dup
>> //ca.idup;
>> // Error: cannot implicitly convert element type const(C) to
>> immutable in ca.idup
>> ca.dup();
>> // result is const(C[])
>> }
>>
>> ----
>>
>> According to what I remember, the name 'idup' had been discussed in the beginning of D2, but it had been disappeared from the need for idup. But it is still oddly name.
>>
>> Using:
>> auto iarr = marr.idup;
>> Instead of :
>> immutable iarr = marr.dup(); // In the future, () would not be
>> necessary
>>
>> Is really handy? Yes, it is 6(or 4) characters shorter. But I can't
>> see it *handy*.
>
>
> What you are missing is that the two code segments are not equivalent.
Hmm, it's right. They are not equivalent.
void main()
{
int[] marr;
auto iarr1 = marr.idup;
immutable iarr2 = marr.dup();
pragma(msg, typeof(iarr1)); // prints immutable(int)[]
pragma(msg, typeof(iarr2)); // prints immutable(int[])
}
It's hard problem...
Kenji Hara
|
September 09, 2012 Re: Eliminate redundancy of dup/idup | ||||
---|---|---|---|---|
| ||||
Posted in reply to kenji hara | kenji hara:
> I've posted two pull requests for the purpose.
This is something related. Are your recent patches allowing code like this, that are two common needs?
void main() {
auto a1 = [1, 2];
auto a2 = [3, 4];
immutable a3 = a1 ~ a2; // line 4
immutable a4 = [10, 20];
immutable a5 = [100];
int[] a6 = a4 ~ a5; // line 7
}
test.d(4): Error: cannot implicitly convert expression (a1 ~ a2) of type int[] to immutable(int[])
test.d(7): Error: cannot implicitly convert expression (a4 ~ a5) of type immutable(int)[] to int[]
Bye,
bearophile
|
September 09, 2012 Re: Eliminate redundancy of dup/idup | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On 9/9/12, Adam D. Ruppe <destructionator@gmail.com> wrote:
> One option I've heard that might be OK is to make auto strip off the top level immutable:
>
> immutable(char[]) a;
> auto b = a; // b is immutable(char)[]
Sounds like something that could bite you in generic code if you expect 'auto' to do nothing more than type inference. is() expressions might start failing, etc..
|
Copyright © 1999-2021 by the D Language Foundation