August 25, 2020
On Friday, 31 July 2020 at 21:49:25 UTC, Mathias LANG wrote:
> Hi everyone,
> For a long time I've been pretty annoyed by the state of `in` parameters.
> In case it needs any clarification, I'm talking at what's between the asterisks (*) here: `void foo (*in* char[] arg)`).
>
> [...]

I think that having `in ref` is preferable than introducing new rules. Everything else makes sense to me, but it's possible I'm missing something.
August 25, 2020
On Tuesday, 25 August 2020 at 12:09:45 UTC, Kagamin wrote:
>
> The backend doesn't know how to load the data. It matters to the programmer, because it affects performance.
>
> Another example:
> void log(in ref int n)
> {
>   write(fd, &n, n.sizeof);
> }
> If the argument here is passed by value, it will need to fiddle with stack and the code will be less optimal.

I assume you imply that it's less optimal because it's taking the address of it ?


> If a non-POD object is passed by value, it will have extra calls to postblit and destructor.

https://github.com/dlang/dmd/blob/master/changelog/preview-in.dd

> - If the type has an elaborate copy or destruction (postblit, copy constructor, destructor),
> the type is always passed by reference.

August 26, 2020
On Tuesday, 25 August 2020 at 14:43:45 UTC, Atila Neves wrote:
> On Friday, 31 July 2020 at 21:49:25 UTC, Mathias LANG wrote:
>> Hi everyone,
>> For a long time I've been pretty annoyed by the state of `in` parameters.
>> In case it needs any clarification, I'm talking at what's between the asterisks (*) here: `void foo (*in* char[] arg)`).
>>
>> [...]
>
> I think that having `in ref` is preferable than introducing new rules. Everything else makes sense to me, but it's possible I'm missing something.

Why is it preferable ? Genuine question here.
I originally had in mind to support `in ref` as being the user forcing `ref` on the param. It just seemed *obvious*. However, after a lot of playing around with it, it wasn't that obvious anymore.
August 26, 2020
On Wednesday, 26 August 2020 at 04:15:21 UTC, Mathias LANG wrote:
> On Tuesday, 25 August 2020 at 14:43:45 UTC, Atila Neves wrote:
>> On Friday, 31 July 2020 at 21:49:25 UTC, Mathias LANG wrote:
>>> Hi everyone,
>>> For a long time I've been pretty annoyed by the state of `in` parameters.
>>> In case it needs any clarification, I'm talking at what's between the asterisks (*) here: `void foo (*in* char[] arg)`).
>>>
>>> [...]
>>
>> I think that having `in ref` is preferable than introducing new rules. Everything else makes sense to me, but it's possible I'm missing something.
>
> Why is it preferable ? Genuine question here.
> I originally had in mind to support `in ref` as being the user forcing `ref` on the param. It just seemed *obvious*. However, after a lot of playing around with it, it wasn't that obvious anymore.

For me, more programmer choice and less magic.
August 26, 2020
On Wednesday, 26 August 2020 at 04:15:21 UTC, Mathias LANG wrote:
> On Tuesday, 25 August 2020 at 14:43:45 UTC, Atila Neves wrote:
>> On Friday, 31 July 2020 at 21:49:25 UTC, Mathias LANG wrote:
>>> Hi everyone,
>>> For a long time I've been pretty annoyed by the state of `in` parameters.
>>> In case it needs any clarification, I'm talking at what's between the asterisks (*) here: `void foo (*in* char[] arg)`).
>>>
>>> [...]
>>
>> I think that having `in ref` is preferable than introducing new rules. Everything else makes sense to me, but it's possible I'm missing something.
>
> Why is it preferable ? Genuine question here.
> I originally had in mind to support `in ref` as being the user forcing `ref` on the param. It just seemed *obvious*. However, after a lot of playing around with it, it wasn't that obvious anymore.

I think it's preferable because it gives more control to the programmer and there's less magic. And also that enregistering and all that probably belongs in the backend.
August 26, 2020
On Wednesday, 26 August 2020 at 09:10:45 UTC, Atila Neves wrote:

> I think it's preferable because it gives more control to the programmer and there's less magic. And also that enregistering and all that probably belongs in the backend.

I like the idea of Herb Sutter's talk [1], where the programmer specifies the semantic behavior of the parameters, instead of the mechanics how to pass them. The programmer specifies `in`, `out`, `inout`, `move` or `forward`. Then the compiler figures out how to achieve the semantics in the most efficient way.

There's nothing in Mathias' proposal that cannot be accomplished today with other attributes? So if you want more control, don't use `in`.

[1] https://youtu.be/qx22oxlQmKc?t=1258

--
/Jacob Carlborg
August 26, 2020
On Tuesday, 25 August 2020 at 14:43:45 UTC, Atila Neves wrote:
>
> I think that having `in ref` is preferable than introducing new rules. Everything else makes sense to me, but it's possible I'm missing something.

I think that the proposal from Mathias LANG meant that 'in' shall not be accompanied with any other qualifier. How the parameter is passed is up to the compiler, if it is by value, reference or something else.

If you explicitly want a reference you use 'ref' just like today.
August 27, 2020
On Tuesday, 25 August 2020 at 16:05:51 UTC, Mathias LANG wrote:
> On Tuesday, 25 August 2020 at 12:09:45 UTC, Kagamin wrote:
>>
>> The backend doesn't know how to load the data. It matters to the programmer, because it affects performance.
>>
>> Another example:
>> void log(in ref int n)
>> {
>>   write(fd, &n, n.sizeof);
>> }
>> If the argument here is passed by value, it will need to fiddle with stack and the code will be less optimal.
>
> I assume you imply that it's less optimal because it's taking the address of it ?

Because it has an extra write to memory, pushing the parameter passed by value to stack to take its address. In general when the parameter is passed by reference somewhere, like the refactoring you did in phobos replacing `in ref` with `scope const ref` - the parameter can be passed to one of those functions that have precise ref semantics. I also wonder how they interact with auto ref.

>> If a non-POD object is passed by value, it will have extra calls to postblit and destructor.
>
> https://github.com/dlang/dmd/blob/master/changelog/preview-in.dd
>
>> - If the type has an elaborate copy or destruction (postblit, copy constructor, destructor),
>> the type is always passed by reference.

If ref semantics doesn't depend on parameter position, then it's fine, but you say it depends.
1 2 3 4
Next ›   Last »