On Sunday, 28 May 2017 at 19:10:49 UTC, ketmar wrote:
> Meta wrote:
>
>> If a parameter is marked as ref then you have to assume it will be modified by the function (unless it's const/inout/immutable). If it's marked as out then you know it will be. If you didn't know that the function takes its parameters by ref or out... You're should've RTFM.
>
> now imagine that you're reading some code:
>
> 	foo(a);
>
> vs:
>
> 	foo(ref a);
>
> which code style is easier to read without constant jumping into documentation?

Is this ever actually a problem in practice?

Anyway, having to add ref or out at the call site will greatly hamper metaprogramming.

That's what C# does. I always liked that a lot, and even argued in favor of doing the same in D (ages ago). It got shot down way back when, so unfortunately, I don't think any reversal is going to happen.

Getting in the way of UFCS and generic code are fair points, although they don't stike me as insurmountable. I think that if D's ref/out params had worked that way from the beginning we would've already hod solutions to those matters. And it does kinda bug me when generic code ends up being a reason to not have a nice benefitial feature for non-generic code, just fwiw :(

In response to any claim that this isn't a real problem in practice, I submit the possibility that, if it indeed isn't a real problem, maybe that's *because* of people (like Stefan and ketmar) simply avoiding the feature entirely so that it *doesn't* become a problem.

On 05/28/2017 03:06 PM, Meta wrote:
> 
> If you didn't know that the function takes its parameters by ref or out... You're should've RTFM.

That's the same reasoning that's been used to excuse just about every API blunder in C's infamously unsafe bug-riddled history.

On Monday, 29 May 2017 at 01:56:19 UTC, Nick Sabalausky (Abscissa) wrote:
> On 05/28/2017 03:06 PM, Meta wrote:
>> 
>> If you didn't know that the function takes its parameters by ref or out... You're should've RTFM.
>
> That's the same reasoning that's been used to excuse just about every API blunder in C's infamously unsafe bug-riddled history.

This is information that a good IDE could be designed to provide. To require "ref" is rather pointless as it would make the feature redundant, just use a pointer and "&" instead and argue in favour of nonnullable static analysis...

On 05/29/2017 12:57 AM, Ola Fosheim Grostad wrote:
> On Monday, 29 May 2017 at 01:56:19 UTC, Nick Sabalausky (Abscissa) wrote:
>> On 05/28/2017 03:06 PM, Meta wrote:
>>>
>>> If you didn't know that the function takes its parameters by ref or out... You're should've RTFM.
>>
>> That's the same reasoning that's been used to excuse just about every API blunder in C's infamously unsafe bug-riddled history.
> 
> This is information that a good IDE could be designed to provide. To require "ref" is rather pointless as it would make the feature redundant, just use a pointer and "&" instead and argue in favour of nonnullable static analysis...

Did you intend that as a response to my post or to the OP? Sounds more like it was directed at the OP.

The web interface really should add an extra "Reply" button way at the bottom that creates a reply to the OP (Or better yet, default to tree view.) I've noticed that the stupid default of "remove all threading information" combined with individual message replies creates a lot of confusion with cases where people try to reply to the OP, but wind up *actually* replying to whatever random leaf just happened the be the latest post (I also suspect the web interface's "remove threading" default is probably also the ultimate source of most of the animosity towards OT. Prentending that there's no threading in an inherently threaded newsgroup just begs for these sorts of problems)

On Monday, 29 May 2017 at 05:39:41 UTC, Nick Sabalausky (Abscissa) wrote:
> Did you intend that as a response to my post or to the OP? Sounds more like it was directed at the OP.

I tried to reply to:

<<That's what C# does. I always liked that a lot, and even argued in favor of doing the same in D (ages ago). It got shot down way back when, so unfortunately, I don't think any reversal is going to happen.>>

But failed... prolly because you had 2 msgs in a row... Sorry.

On Sunday, 28 May 2017 at 17:54:30 UTC, WebFreak001 wrote:
> Should the language spec say that those functions should get called with `foo(ref input);` so that surprises like this where the user doesn't check the docs/implementation can't happen (like in C#)?

I think it's mostly about good taste on what you define functions to take as ref input. I have a feeling the present way is not a big problem in practice because it is intuitive somehow. Besides, member functions mutate their class/struct anyway, and we don't want to lose our ability to call extension funcions with same syntax as member ones.

Same thing as with struct/class separation: in principle it sounds pointless that whether used by value or by ref has to be defined with the type, but it somehow just works intuitively in practice. (My personal experience. Don't know if others feel the same way)

But what would be worth a consideration, is that perhaps one should be allowed to pass rvalues as reference with something like this? According to TDPL, ref arguments do not take rvalues to prevent bugs where you accidently copy something before passing it, and that's a good rationale. But shouldn't it still be allowed explicitly?

On Monday, 29 May 2017 at 07:39:40 UTC, Dukc wrote:

> But what would be worth a consideration, is that perhaps one should be allowed to pass rvalues as reference with something like this? According to TDPL, ref arguments do not take rvalues to prevent bugs where you accidently copy something before passing it, and that's a good rationale. But shouldn't it still be allowed explicitly?

Explicitly? It is:

import std.stdio;

struct S
{
    int v;
}

void foo(ref S s)
{
    writeln("took S by ref: ", s.v);
}

void foo(S s)
{
    writeln("took rvalue S...");
    foo(s);      // calls ref overload
}

void main()
{
    S s;
    foo(s);      // calls ref overload
    foo(S.init); // calls rvalue overload
}

And for templates we have auto ref.

On Monday, May 29, 2017 07:39:40 Dukc via Digitalmars-d wrote:
> But what would be worth a consideration, is that perhaps one should be allowed to pass rvalues as reference with something like this? According to TDPL, ref arguments do not take rvalues to prevent bugs where you accidently copy something before passing it, and that's a good rationale. But shouldn't it still be allowed explicitly?

I expect that we're going to see a DIP related to rvalue references at some point here, because some of the folks (particularly the game folks) think that it's critical to be able to have a function that doesn't care whether it's taking a value by value or by ref - just that it takes it efficiently, and they don't want to be forced to use auto ref to do it (since that requires templates).

- Jonathan M Davis

Meta wrote:

> On Sunday, 28 May 2017 at 19:10:49 UTC, ketmar wrote:
>> Meta wrote:
>>
>>> If a parameter is marked as ref then you have to assume it will be modified by the function (unless it's const/inout/immutable). If it's marked as out then you know it will be. If you didn't know that the function takes its parameters by ref or out... You're should've RTFM.
>>
>> now imagine that you're reading some code:
>>
>> 	foo(a);
>>
>> vs:
>>
>> 	foo(ref a);
>>
>> which code style is easier to read without constant jumping into documentation?
>
> Is this ever actually a problem in practice?

yes. aliced has this syntax for a long time. for a reason. and i must say that i'm adding alot of random features to aliced, but very little of 'em survives.

> Anyway, having to add ref or out at the call site will greatly hamper metaprogramming.

not more then "&" does. except with `auto ref` -- which is misdesigned feature anyway (forcing programmer to do the work compiler can do without any external help is not a good design; besides, compiler can do that work *better*).