Jump to page: 1 210  
Page
Thread overview
DIP 1016--ref T accepts r-values--Community Review Round 1
Jul 20, 2018
Mike Parker
Jul 20, 2018
Nicholas Wilson
Jul 20, 2018
Dukc
Jul 20, 2018
Bastiaan Veelo
Jul 20, 2018
Dukc
Jul 20, 2018
Nicholas Wilson
Jul 20, 2018
Dgame
Jul 20, 2018
Seb
Jul 20, 2018
Dgame
Jul 20, 2018
Seb
Jul 20, 2018
Manu
Jul 20, 2018
Dukc
Jul 20, 2018
Nicholas Wilson
Jul 21, 2018
Dukc
Jul 20, 2018
Manu
Jul 20, 2018
Bastiaan Veelo
Jul 20, 2018
Manu
Jul 20, 2018
Manu
Jul 20, 2018
Timoses
Jul 20, 2018
Seb
Jul 20, 2018
Manu
Jul 20, 2018
Manu
Jul 20, 2018
Jonathan M Davis
Jul 20, 2018
Daniel N
Jul 20, 2018
Jonathan M Davis
Jul 20, 2018
meppl
Jul 20, 2018
Jonathan M Davis
Jul 22, 2018
Marco Leise
Jul 20, 2018
aliak
Jul 20, 2018
Jonathan M Davis
Jul 20, 2018
Daniel N
Jul 20, 2018
Jonathan M Davis
Jul 20, 2018
Manu
Jul 20, 2018
Radu
Jul 20, 2018
Manu
Jul 20, 2018
Jonathan M Davis
Jul 20, 2018
Jonathan M Davis
Jul 20, 2018
Manu
Jul 20, 2018
Elie Morisse
Jul 20, 2018
Manu
Jul 20, 2018
Jonathan M Davis
Jul 21, 2018
Nicholas Wilson
Jul 21, 2018
Jonathan M Davis
Jul 21, 2018
Manu
Jul 21, 2018
Manu
Jul 21, 2018
Jonathan M Davis
Jul 25, 2018
Jim Balter
Jul 21, 2018
Manu
Jul 21, 2018
Jonathan M Davis
Jul 21, 2018
Nicholas Wilson
Jul 21, 2018
Manu
Jul 21, 2018
Johannes Loher
Jul 21, 2018
Johannes Loher
Jul 21, 2018
Manu
Jul 22, 2018
Johannes Loher
Jul 22, 2018
Manu
Jul 22, 2018
Bastiaan Veelo
Jul 22, 2018
Jonathan M Davis
Jul 25, 2018
ShadoLight
Jul 25, 2018
Atila Neves
Jul 25, 2018
Manu
Jul 25, 2018
Manu
Jul 26, 2018
Atila Neves
Jul 21, 2018
Johnatune
Jul 21, 2018
Manu
Jul 21, 2018
Paolo Invernizzi
Jul 21, 2018
JohnB
Jul 21, 2018
Paolo Invernizzi
Jul 21, 2018
12345swordy
Jul 25, 2018
Marco Leise
Jul 25, 2018
Paolo Invernizzi
Jul 25, 2018
Manu
Jul 25, 2018
Jim Balter
Jul 25, 2018
Manu
Jul 25, 2018
Paolo Invernizzi
Jul 25, 2018
rikki cattermole
Jul 25, 2018
12345swordy
Jul 25, 2018
Paolo Invernizzi
Jul 25, 2018
12345swordy
Jul 25, 2018
Paolo Invernizzi
Jul 25, 2018
12345swordy
Jul 25, 2018
Manu
Jul 25, 2018
aliak
Nov 08, 2018
Vijay Nayar
Nov 09, 2018
Manu
Nov 09, 2018
Q. Schroll
Nov 10, 2018
Manu
Nov 10, 2018
Neia Neutuladh
Nov 10, 2018
Manu
Jul 21, 2018
kinke
July 20, 2018
This is the feedback thread for the first round of Community Review for DIP 1016, "ref T accepts r-values":

https://github.com/dlang/DIPs/blob/725541d69149bc85a9492f7df07360f8e2948bd7/DIPs/DIP1016.md

All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on August 3, or when I make a post declaring it complete.

At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the Final Review and Formal Assessment by the language maintainers.

Please familiarize yourself with the documentation for the Community Review before participating.

https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review

Thanks in advance to all who participate.


July 20, 2018
On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1016, "ref T accepts r-values":
>
> https://github.com/dlang/DIPs/blob/725541d69149bc85a9492f7df07360f8e2948bd7/DIPs/DIP1016.md
>
+1

The DIP reduces bloat, doesn't brake existing code, and I can't see downsides.
July 20, 2018
On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1016, "ref T accepts r-values"

I'd prefer a solution which allows one to make an invisible temp manually without making a new statement or a new symbol name. By appending something (like .byRef or byRef!long, the latter making an implicit type conversion) after a rvalue statement. This would still prevent things like byRefFunction(aVariable.incremented) when incremented copies the value without the user excepting it.

But If the options are either your solution or the present situation, yours is still better. Thanks for the effort to make it... I believe Manu will be pleased.
July 20, 2018
On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1016, "ref T accepts r-values":
>
> https://github.com/dlang/DIPs/blob/725541d69149bc85a9492f7df07360f8e2948bd7/DIPs/DIP1016.md

The only difficulty I had was reading
> An example may be some meta that reflects or receives a function by alias.
My difficulties are with the word “meta” used as a noun and what “reflecting a function” means. I think I would have worded it as
> An example may be some template with an ‘alias’ parameter that is instantiated on a function.

Otherwise, good work, I think!
July 20, 2018
On Friday, 20 July 2018 at 09:03:18 UTC, Dukc wrote:
> Thanks for the effort to make it... I believe Manu will be pleased.

Manu is the one who wrote the DIP :-)
July 20, 2018
On Friday, 20 July 2018 at 09:03:18 UTC, Dukc wrote:
> appending something (like .byRef or byRef!long, the latter making an implicit type conversion)

That can't work: either it returns an expired stack temporary (*very* bad), or allocates with no way to deallocate (bad).
July 20, 2018
On Friday, 20 July 2018 at 08:12:00 UTC, Dominikus Dittes Scherkl wrote:
> On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review for DIP 1016, "ref T accepts r-values":
>>
>> https://github.com/dlang/DIPs/blob/725541d69149bc85a9492f7df07360f8e2948bd7/DIPs/DIP1016.md
>>
> +1
>
> The DIP reduces bloat, doesn't brake existing code, and I can't see downsides.

Couldn't have put it better.
July 20, 2018
On Friday, 20 July 2018 at 09:39:47 UTC, Nicholas Wilson wrote:
> On Friday, 20 July 2018 at 09:03:18 UTC, Dukc wrote:
>> appending something (like .byRef or byRef!long, the latter making an implicit type conversion)
>
> That can't work: either it returns an expired stack temporary (*very* bad), or allocates with no way to deallocate (bad).

What about something like this?

----
import std.stdio;

ref T byRef(T)(T value) {
    static T _val = void;
    _val = value;

    return _val;
}

void foo(ref int a) {
    writeln("A = ", a);
}

void main() {
    foo(42.byRef);
    foo(23.byRef);
}
----

July 20, 2018
On Friday, 20 July 2018 at 10:08:03 UTC, Dgame wrote:
> On Friday, 20 July 2018 at 09:39:47 UTC, Nicholas Wilson wrote:
>> On Friday, 20 July 2018 at 09:03:18 UTC, Dukc wrote:
>>> appending something (like .byRef or byRef!long, the latter making an implicit type conversion)
>>
>> That can't work: either it returns an expired stack temporary (*very* bad), or allocates with no way to deallocate (bad).
>
> What about something like this?
>
> ----
> import std.stdio;
>
> ref T byRef(T)(T value) {
>     static T _val = void;
>     _val = value;
>
>     return _val;
> }
>
> void foo(ref int a) {
>     writeln("A = ", a);
> }
>
> void main() {
>     foo(42.byRef);
>     foo(23.byRef);
> }
> ----

That can't work, consider e.g.:

foo(10.byRef, 20.byRef); // calls foo with (20, 20)

https://run.dlang.io/is/lazeu2
July 20, 2018
On Friday, 20 July 2018 at 10:08:03 UTC, Dgame wrote:
> On Friday, 20 July 2018 at 09:39:47 UTC, Nicholas Wilson wrote:
>> On Friday, 20 July 2018 at 09:03:18 UTC, Dukc wrote:
>>> appending something (like .byRef or byRef!long, the latter making an implicit type conversion)
>>
>> That can't work: either it returns an expired stack temporary (*very* bad), or allocates with no way to deallocate (bad).
>
> What about something like this?
>
> ----
> import std.stdio;
>
> ref T byRef(T)(T value) {
>     static T _val = void;
>     _val = value;
>
>     return _val;
> }
>
> void foo(ref int a) {
>     writeln("A = ", a);
> }
>
> void main() {
>     foo(42.byRef);
>     foo(23.byRef);
> }
> ----

Perhaps semantically correct, but practically a non-starter, due to the performance implications of loading and storing to thread-local storage and by extension the severe impact on compiler optimizations. And also syntactically ugly, even if you shorten it to something like `1.r`.

Anyway, I think the DIP is the best way forward - just remove the stupid and unnecessary restriction.
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10