Call site 'ref'

Robert Jacques sandford at jhu.edu
Sun Jan 15 09:57:18 PST 2012


On Sun, 15 Jan 2012 07:36:53 -0600, Alex Rønne Petersen <xtzgzorex at gmail.com> wrote:
> 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?

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. :)

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);

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?
3b) What do programmers experienced in X and in D/C++/C/etc think about that particular feature (good/bad/ugly)?

4) When presenting problematic language use case and an associated proposed solution, being light on details/analysis and missing the second most obvious drawbacks of your proposed solution will cause your argument to be dismissed by many people. In short, if you're not willing to fully think through your idea, why should we take the time to too? That aside, if you are serious about this topic, you might want to have a look at/submit a D improvement proposal (http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs).


More information about the Digitalmars-d mailing list