May 04, 2013 Re: Rvalue references - The resolution | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | On 5/4/2013 4:03 PM, Andrej Mitrovic wrote: > On 5/4/13, Walter Bright <newshound2@digitalmars.com> wrote: >> Andrei & I argued that we needed to make it work with just ref annotations. > > So to recap, 2.063 turns slices into r-values which will break code > that used ref, e.g.: > > ----- > void parse(ref int[] arr) { } > > void main() > { > int[] arr = [1, 2]; > parse(arr[]); // ok in 2.062, error in 2.063 > } > ----- Do you mean that is an error now with HEAD? > Then the user might introduce a non-ref overload: > > ----- > void parse(ref int[] arr) { } > void parse(int[] arr) { } // picks this one > ----- > > And later down the road, maybe even in 2.064, ref will take r-values > making the new code error because of ambiguity between the two > functions. > > Has code breakage ever been taken into account during this dconf conversation? I don't know of any code it would break. |
May 04, 2013 Re: Rvalue references - The resolution | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Saturday, 4 May 2013 at 23:31:39 UTC, Walter Bright wrote:
> On 5/4/2013 3:51 PM, w0rp wrote:
>> Does all of this also mean that a
>> function with a ref parameter will automagically work with r-values?
>
> Yes.
This is good, but not I'm a bit bitter with the whole code breakage of slice are rvalues that happened recently.
This is what I refers to when I complain about the way D is released. Both changes are super good, but we should have gotten both AT ONCE. And while the second isn't there, I should have none and still get bug fixes.
|
May 04, 2013 Re: Rvalue references - The resolution | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 5/4/2013 4:34 PM, Walter Bright wrote:
>> And later down the road, maybe even in 2.064, ref will take r-values
>> making the new code error because of ambiguity between the two
>> functions.
>>
>> Has code breakage ever been taken into account during this dconf conversation?
I see what you mean now. You mean how does an rvalue overload if faced with T and ref T. Currently:
void foo(ref int i);
void foo(int i);
void main() {
int i;
foo(i); // matches ref int
foo(1); // matches int
}
I don't think that should change with this proposal.
|
May 04, 2013 Re: Rvalue references - The resolution | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Saturday, 4 May 2013 at 23:44:27 UTC, Walter Bright wrote:
> On 5/4/2013 4:34 PM, Walter Bright wrote:
>>> And later down the road, maybe even in 2.064, ref will take r-values
>>> making the new code error because of ambiguity between the two
>>> functions.
>>>
>>> Has code breakage ever been taken into account during this dconf conversation?
>
> I see what you mean now. You mean how does an rvalue overload if faced with T and ref T. Currently:
>
> void foo(ref int i);
> void foo(int i);
>
> void main() {
> int i;
> foo(i); // matches ref int
> foo(1); // matches int
> }
>
> I don't think that should change with this proposal.
What about this:
void foo(ref int i);
void foo(ref const(int) i);
void main() {
int i;
foo(i);
foo(1);
}
What do they match here?
|
May 04, 2013 Re: Rvalue references - The resolution | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 05/05/2013 01:30 AM, Walter Bright wrote:
> On 5/4/2013 3:50 PM, deadalnix wrote:
>> Require isn't the right word, or you hav to explain yourself much more.
>
> You need an explicit annotation if a ref parameter is returned by ref by
> that function. This is what Rust's annotations do.
>
> Consider:
>
> ref T foob(ref U u) { return u.t; }
>
> ref U bar() { U u; return foob(u); }
>
> The compiler cannot know that the ref return of foob is referring to
> local u (as opposed to, say, a ref to a global) unless it is annotated
> to say so. Rust is no different.
What is the point? Rust conservatively assumes this by default.
|
May 04, 2013 Re: Rvalue references - The resolution | ||||
---|---|---|---|---|
| ||||
Posted in reply to Diggory | On 5/4/2013 4:47 PM, Diggory wrote:
> What about this:
>
> void foo(ref int i);
> void foo(ref const(int) i);
>
> void main() {
> int i;
> foo(i);
> foo(1);
> }
>
> What do they match here?
An rvalue ref is not const, so (1) would match the same as (i) does.
|
May 04, 2013 Re: Rvalue references - The resolution | ||||
---|---|---|---|---|
| ||||
Posted in reply to Diggory | On 05/05/2013 01:47 AM, Diggory wrote:
> On Saturday, 4 May 2013 at 23:44:27 UTC, Walter Bright wrote:
>> On 5/4/2013 4:34 PM, Walter Bright wrote:
>>>> And later down the road, maybe even in 2.064, ref will take r-values
>>>> making the new code error because of ambiguity between the two
>>>> functions.
>>>>
>>>> Has code breakage ever been taken into account during this dconf
>>>> conversation?
>>
>> I see what you mean now. You mean how does an rvalue overload if faced
>> with T and ref T. Currently:
>>
>> void foo(ref int i);
>> void foo(int i);
>>
>> void main() {
>> int i;
>> foo(i); // matches ref int
>> foo(1); // matches int
>> }
>>
>> I don't think that should change with this proposal.
>
> What about this:
>
> void foo(ref int i);
> void foo(ref const(int) i);
>
> void main() {
> int i;
> foo(i);
> foo(1);
> }
>
> What do they match here?
Both match the first overload because that is an exact match whereas the second overload is only a match with conversion to const.
|
May 04, 2013 Re: Rvalue references - The resolution | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | On 5/4/2013 4:36 PM, deadalnix wrote:
> This is good, but not I'm a bit bitter with the whole code breakage of slice are
> rvalues that happened recently.
I know that code breakage sux.
|
May 04, 2013 Re: Rvalue references - The resolution | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Saturday, 4 May 2013 at 23:56:09 UTC, Walter Bright wrote:
> On 5/4/2013 4:36 PM, deadalnix wrote:
>> This is good, but not I'm a bit bitter with the whole code breakage of slice are
>> rvalues that happened recently.
>
> I know that code breakage sux.
And in this case, this was avoidable. We MUST get better at releasing versions of D.
|
May 05, 2013 Re: Rvalue references - The resolution | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Saturday, 4 May 2013 at 23:30:01 UTC, Walter Bright wrote:
> On 5/4/2013 3:50 PM, deadalnix wrote:
>> Require isn't the right word, or you hav to explain yourself much more.
>
> You need an explicit annotation if a ref parameter is returned by ref by that function. This is what Rust's annotations do.
>
> Consider:
>
> ref T foob(ref U u) { return u.t; }
>
> ref U bar() { U u; return foob(u); }
>
> The compiler cannot know that the ref return of foob is referring to local u (as opposed to, say, a ref to a global) unless it is annotated to say so. Rust is no different.
This code sample won't require any annotation in Rust. And it illustrate wonderfully what I'm saying : most people in the discussion (and it has been shown now that this includes you) were unaware of how does Rust solve the problem.
I don't think excluding a solution that isn't understood is the smartest thing to do.
|
Copyright © 1999-2021 by the D Language Foundation