January 16, 2012
On 1/15/12 6:30 PM, Peter Alexander wrote:
> On 15/01/12 11:56 PM, Jonathan M Davis wrote:
>> On Monday, January 16, 2012 00:41:14 Timon Gehr wrote:
>>> Well, struct literals are lvalues, at least in DMD.
>>
>> Yeah. I don't understand that. I've argued about it with Walter before.
>> Apparently they are in C++ as well. I don't understand it. It makes it
>> so that
>
> In C++, struct literals are rvalues. C++ just has a special rule that
> const references can bind to rvalues (but non-const references cannot),

That's a bad rule that we shouldn't copy.

Andrei
January 16, 2012
On 01/16/2012 01:35 AM, Andrei Alexandrescu wrote:
> On 1/15/12 6:30 PM, Peter Alexander wrote:
>> On 15/01/12 11:56 PM, Jonathan M Davis wrote:
>>> On Monday, January 16, 2012 00:41:14 Timon Gehr wrote:
>>>> Well, struct literals are lvalues, at least in DMD.
>>>
>>> Yeah. I don't understand that. I've argued about it with Walter before.
>>> Apparently they are in C++ as well. I don't understand it. It makes it
>>> so that
>>
>> In C++, struct literals are rvalues. C++ just has a special rule that
>> const references can bind to rvalues (but non-const references cannot),
>
> That's a bad rule that we shouldn't copy.
>
> Andrei

What do you think is an optimal rule regarding struct literals/lvalues/rvalues and ref parameters?
January 16, 2012
On 16/01/12 12:35 AM, Andrei Alexandrescu wrote:
> On 1/15/12 6:30 PM, Peter Alexander wrote:
>> On 15/01/12 11:56 PM, Jonathan M Davis wrote:
>>> On Monday, January 16, 2012 00:41:14 Timon Gehr wrote:
>>>> Well, struct literals are lvalues, at least in DMD.
>>>
>>> Yeah. I don't understand that. I've argued about it with Walter before.
>>> Apparently they are in C++ as well. I don't understand it. It makes it
>>> so that
>>
>> In C++, struct literals are rvalues. C++ just has a special rule that
>> const references can bind to rvalues (but non-const references cannot),
>
> That's a bad rule that we shouldn't copy.

I agree.
January 16, 2012
On 1/15/12 6:38 PM, Timon Gehr wrote:
> On 01/16/2012 01:35 AM, Andrei Alexandrescu wrote:
>> On 1/15/12 6:30 PM, Peter Alexander wrote:
>>> On 15/01/12 11:56 PM, Jonathan M Davis wrote:
>>>> On Monday, January 16, 2012 00:41:14 Timon Gehr wrote:
>>>>> Well, struct literals are lvalues, at least in DMD.
>>>>
>>>> Yeah. I don't understand that. I've argued about it with Walter before.
>>>> Apparently they are in C++ as well. I don't understand it. It makes it
>>>> so that
>>>
>>> In C++, struct literals are rvalues. C++ just has a special rule that
>>> const references can bind to rvalues (but non-const references cannot),
>>
>> That's a bad rule that we shouldn't copy.
>>
>> Andrei
>
> What do you think is an optimal rule regarding struct
> literals/lvalues/rvalues and ref parameters?

auto ref

Andrei
January 16, 2012
On Sun, 15 Jan 2012 12:27:46 -0600, Peter Alexander <peter.alexander.au@gmail.com> wrote:
> On 15/01/12 5:57 PM, Robert Jacques wrote:
>> On Sun, 15 Jan 2012 07:36:53 -0600, Alex Rønne Petersen
>>> Thoughts?
>>
>> In no particular order:
>>
>> 1) Adding ref to the call site is lexically similar to Hungarian
>> notation and has all the drawbacks and advantages thereof. I know
>> invoking Hungarian notation is almost an invocation of Godwin's law when
>> it comes to programming syntax discussions, but Hungarian notation was
>> introduced for a reason; there was a time when for large software
>> projects it dramatically increases code comprehension (and thus quality)
>> for the code reviewer and/or code maintainer. And that argument still
>> stand today for anyone _not_ using a modern IDE. The primary reason
>> Hungarian notation is disparaged today is that IDEs evolved beyond
>> emacs, vim and notepad. Once they could tell the programmer with a
>> tooltip what every variable's type was, the need to encode the type in
>> the variable name vanished. Or more to the original point, modern IDEs
>> already list function parameter's type and type modifiers (i.e. aka) as
>> you type the function in so it's _always_ obvious what is ref/const/etc
>> and what is not. And for the code reviewer, ref parameters could be auto
>> highlighted/underlined/etc to easy their job. Yes, this issue does need
>> to be addressed, but I don't think that this is fundamentally a language
>> problem; it more a lack of modern tools for D. That reminds me, I need
>> to check out the latest revision of Visual D. :)
>
> A fair point, but:
>
> a) D doesn't have much in terms of *free* highly-featured IDEs.
Both DDT and Visual D are a *free* highly-featured IDE.

> b) Even if it did, lots of people still use emacs/vim.
So, you're proposing to "fix" the language instead of using a better dev environment? Like stick shift drivers and *nix sys admins, coders who use emacs/vim actively acknowledge that the onus for writing correct code is on their shoulders; there are not going to be any red-squiggles, line re-formatting or code completion to "get in the way"/"help them".

> c) That does not help when glancing at code to find where a variable is
> modified.
First, if the IDE colors every variable passed by ref blue, those are definitely going to jump off the page when glancing through code. Second, since when does _glancing_ at an unfamiliar piece of code every give meaningful results? Any reasonable code review (using a good IDE) will entail the reviewer checking the doc comments on any unfamiliar function.

>> 2) It is perfectly possible to write functions in D that require
>> explicit demarcation at the call site:
>>
>> int foo( int* v ) { return *x; }
>>
>> int y;
>> int z = foo(@y);
>
> True, but these aren't the same. Pointers can be reseated, ref
> parameters cannot.

Well, if the final storage class was brought back into the language...

> Pointers may also be null, encouraging needless null
> pointer checks.

Needless null pointer checks are only a possible problem in release code; assert solves that problem nicely.

>> 3) Mandating ref at the call is currently how C# handles reference
>> parameters. Anytime someone suggests a feature from another language,
>> particularly C# or Java, two questions are immediately raised in my mind.
>> 3a) Does the asker simply want D to be more like language X?
>
> Perhaps, perhaps not. I think it is better to evaluate a suggestion on
> its merit and not on the suggester's motivation.

Before I can evaluate your use case, let alone your suggestion I need to understand and filter your biases. It's really important to understand how much of a poster's frustration simply come from the cognitive disconnect between two different programming languages and the actual features and capabilities of D.

>> 3b) What do programmers experienced in X and in D/C++/C/etc think about
>> that particular feature (good/bad/ugly)?
>
> Mandated ref is well-received in C# as far as I'm aware.

And C# has never had non mandated ref; this is both a good and bad thing. It's a bad thing as a positive response to ref gets mixed with mandated ref. It's good thing because there's probably a developer blog or two you could link too providing good support by industry experts for your argument.

> I also know that people dislike using reference parameters in C++ due to
> the lack of visibility at the call site (causing them to use pointers).

From the C++ FQA on references:
"Note: Old line C programmers sometimes don't like references since they provide reference semantics that isn't explicit in the caller's code. After some C++ experience, however, one quickly realizes this is a form of information hiding, which is an asset rather than a liability. E.g., programmers should write code in the language of the problem rather than the language of the machine."

From Google's Style Guidelines:
Within function parameter lists all references must be const: void Foo(const string &in, string *out);
In fact it is a very strong convention in Google code that input arguments are values or const references while output arguments are pointers. Input parameters may be const pointers, but we never allow non-const reference parameters.
January 16, 2012
On 01/16/2012 02:00 AM, Andrei Alexandrescu wrote:
> On 1/15/12 6:38 PM, Timon Gehr wrote:
>> On 01/16/2012 01:35 AM, Andrei Alexandrescu wrote:
>>> On 1/15/12 6:30 PM, Peter Alexander wrote:
>>>> On 15/01/12 11:56 PM, Jonathan M Davis wrote:
>>>>> On Monday, January 16, 2012 00:41:14 Timon Gehr wrote:
>>>>>> Well, struct literals are lvalues, at least in DMD.
>>>>>
>>>>> Yeah. I don't understand that. I've argued about it with Walter
>>>>> before.
>>>>> Apparently they are in C++ as well. I don't understand it. It makes it
>>>>> so that
>>>>
>>>> In C++, struct literals are rvalues. C++ just has a special rule that
>>>> const references can bind to rvalues (but non-const references cannot),
>>>
>>> That's a bad rule that we shouldn't copy.
>>>
>>> Andrei
>>
>> What do you think is an optimal rule regarding struct
>> literals/lvalues/rvalues and ref parameters?
>
> auto ref
>
> Andrei

But that only works for templates?
January 16, 2012
2012/1/15 Alex Rønne Petersen <xtzgzorex@gmail.com>:
> Hi,
>
> I don't know how many times I've made the mistake of passing a local variable to a function which takes a 'ref' parameter. Suddenly, local variables/fields are just mutating out of nowhere, because it's not at all obvious that a function you're calling is taking a 'ref' parameter. This is particularly true for std.utf.decode().
>
> Yes, I realize I could look at the function declaration. Yes, I could read the docs too. But that doesn't prevent me from forgetting that a function takes a 'ref' parameter, and then doing the mistake again. The damage is done, and the time is wasted.
>
> I think D should allow 'ref' on call sites to prevent these mistakes. For example:
>
> string str = ...;
> size_t pos;
> auto chr = std.utf.decode(str, ref pos);
>
> Now it's much more obvious that the parameter is passed by reference and is going to be mutated.
>
> Ideally, this would not be optional, but rather *required*, but I realize that such a change would break a *lot* of code, so that's probably not a good idea.
>
> Thoughts?
>
> --
> - Alex

I don't see how call cite ref will help the issue. If you don't read ddoc, how will you know what exactly function does with it's ref parameter - statistically? Knowing that function takes parameter by ref doesn't help understanding it's logic. Also, knowing that function doesn't take any ref parameters doesn't mean you don't need to read it's documentation.
January 16, 2012
On 16-01-2012 02:37, Mail Mantis wrote:
> 2012/1/15 Alex Rønne Petersen<xtzgzorex@gmail.com>:
>> Hi,
>>
>> I don't know how many times I've made the mistake of passing a local
>> variable to a function which takes a 'ref' parameter. Suddenly, local
>> variables/fields are just mutating out of nowhere, because it's not at all
>> obvious that a function you're calling is taking a 'ref' parameter. This is
>> particularly true for std.utf.decode().
>>
>> Yes, I realize I could look at the function declaration. Yes, I could read
>> the docs too. But that doesn't prevent me from forgetting that a function
>> takes a 'ref' parameter, and then doing the mistake again. The damage is
>> done, and the time is wasted.
>>
>> I think D should allow 'ref' on call sites to prevent these mistakes. For
>> example:
>>
>> string str = ...;
>> size_t pos;
>> auto chr = std.utf.decode(str, ref pos);
>>
>> Now it's much more obvious that the parameter is passed by reference and is
>> going to be mutated.
>>
>> Ideally, this would not be optional, but rather *required*, but I realize
>> that such a change would break a *lot* of code, so that's probably not a
>> good idea.
>>
>> Thoughts?
>>
>> --
>> - Alex
>
> I don't see how call cite ref will help the issue. If you don't read
> ddoc, how will you know what exactly function does with it's ref
> parameter - statistically? Knowing that function takes parameter by
> ref doesn't help understanding it's logic. Also, knowing that function
> doesn't take any ref parameters doesn't mean you don't need to read
> it's documentation.

You may remember what the function does, but forget that it mutates an input parameter.

--
- Alex
January 16, 2012
On 01/16/2012 08:31 AM, Alex Rønne Petersen wrote:
> On 16-01-2012 02:37, Mail Mantis wrote:
>> 2012/1/15 Alex Rønne Petersen<xtzgzorex@gmail.com>:
>>> Hi,
>>>
>>> I don't know how many times I've made the mistake of passing a local
>>> variable to a function which takes a 'ref' parameter. Suddenly, local
>>> variables/fields are just mutating out of nowhere, because it's not
>>> at all
>>> obvious that a function you're calling is taking a 'ref' parameter.
>>> This is
>>> particularly true for std.utf.decode().
>>>
>>> Yes, I realize I could look at the function declaration. Yes, I could
>>> read
>>> the docs too. But that doesn't prevent me from forgetting that a
>>> function
>>> takes a 'ref' parameter, and then doing the mistake again. The damage is
>>> done, and the time is wasted.
>>>
>>> I think D should allow 'ref' on call sites to prevent these mistakes.
>>> For
>>> example:
>>>
>>> string str = ...;
>>> size_t pos;
>>> auto chr = std.utf.decode(str, ref pos);
>>>
>>> Now it's much more obvious that the parameter is passed by reference
>>> and is
>>> going to be mutated.
>>>
>>> Ideally, this would not be optional, but rather *required*, but I
>>> realize
>>> that such a change would break a *lot* of code, so that's probably not a
>>> good idea.
>>>
>>> Thoughts?
>>>
>>> --
>>> - Alex
>>
>> I don't see how call cite ref will help the issue. If you don't read
>> ddoc, how will you know what exactly function does with it's ref
>> parameter - statistically? Knowing that function takes parameter by
>> ref doesn't help understanding it's logic. Also, knowing that function
>> doesn't take any ref parameters doesn't mean you don't need to read
>> it's documentation.
>
> You may remember what the function does, but forget that it mutates an
> input parameter.
>
> --
> - Alex

This statement is self-contradictory.
January 17, 2012
On 1/15/2012 5:37 PM, Mail Mantis wrote:
> I don't see how call cite ref will help the issue. If you don't read ddoc, how will you know what exactly function does with it's ref parameter - statistically? Knowing that function takes parameter by ref doesn't help understanding it's logic. Also, knowing that function doesn't take any ref parameters doesn't mean you don't need to read it's documentation. 
"If the documentation explains it, the code doesn't need to."

?!?!?

Documentation is frequently out of date, but code isn't.
And ideally, the code wouldn't NEED documentation, BECAUSE it SAYS what it's doing.