View mode: basic / threaded / horizontal-split · Log in · Help
January 15, 2012
Call site 'ref'
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
January 15, 2012
Re: Call site 'ref'
You are, lazy, sir, and your programming license should be revoked.

By that logic we should dull all knives because somebody might get hurt.

My 2c.
January 15, 2012
Re: Call site 'ref'
On 15/01/12 1:56 PM, Johnatan Frakes wrote:
> You are, lazy, sir, and your programming license should be revoked.
>
> By that logic we should dull all knives because somebody might get hurt.
>
> My 2c.

This has nothing to do with laziness. It's an error-detection mechanism, 
just like many other language features (e.g. override, const, immutable, 
shared, ...).

I agree with requiring ref at the call site in principle, although it 
would be too much of a breaking change to introduce now. Perhaps allow 
it, and issue a warning if not used?
January 15, 2012
Re: Call site 'ref'
On 15-01-2012 14:56, Johnatan Frakes wrote:
> You are, lazy, sir, and your programming license should be revoked.
>
> By that logic we should dull all knives because somebody might get hurt.
>
> My 2c.

By your logic, we should remove all compiler checks that help avoid 
typical mistakes. This is not about one extreme or another; it's about 
striking the right balance.

This is not the first time this issue has been brought up, and there's a 
reason for that.

--
- Alex
January 15, 2012
Re: Call site 'ref'
On 15-01-2012 15:12, Peter Alexander wrote:
> On 15/01/12 1:56 PM, Johnatan Frakes wrote:
>> You are, lazy, sir, and your programming license should be revoked.
>>
>> By that logic we should dull all knives because somebody might get hurt.
>>
>> My 2c.
>
> This has nothing to do with laziness. It's an error-detection mechanism,
> just like many other language features (e.g. override, const, immutable,
> shared, ...).
>
> I agree with requiring ref at the call site in principle, although it
> would be too much of a breaking change to introduce now. Perhaps allow
> it, and issue a warning if not used?

That sounds reasonable to me. Maybe make it a compiler option like 
-property though? -callsiteref? Something like that.

--
- Alex
January 15, 2012
Re: Call site 'ref'
Alex Rønne Petersen wrote:
> 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?

Good idea, but it should be optional. On by default maybe, but 
optional.
January 15, 2012
Re: Call site 'ref'
On 15-01-2012 15:05, F i L wrote:
> Alex Rønne Petersen wrote:
>> 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?
>
> Good idea, but it should be optional. On by default maybe, but optional.

Absolutely. It would break way too much code if it was made an error. I 
think Peter Alexander's suggestion would work nicely.

--
- Alex
January 15, 2012
Re: Call site 'ref'
On 1/15/2012 8:36 AM, Alex Rønne Petersen 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?
>

This would break UFCS severely.  The following would no longer work:

auto arr = [1, 2, 3, 4, 5];
arr.popFront();  // popFront takes arr by ref
January 15, 2012
Re: Call site 'ref'
On 15/01/12 3:19 PM, dsimcha wrote:
> On 1/15/2012 8:36 AM, Alex Rønne Petersen 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?
>>
>
> This would break UFCS severely. The following would no longer work:
>
> auto arr = [1, 2, 3, 4, 5];
> arr.popFront(); // popFront takes arr by ref

Unless it was ignored for UFCS, which is reasonable, since foo.bar() 
looks like it could modify foo whereas bar(foo) doesn't in general.
January 15, 2012
Re: Call site 'ref'
On 15-01-2012 16:47, Peter Alexander wrote:
> On 15/01/12 3:19 PM, dsimcha wrote:
>> On 1/15/2012 8:36 AM, Alex Rønne Petersen 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?
>>>
>>
>> This would break UFCS severely. The following would no longer work:
>>
>> auto arr = [1, 2, 3, 4, 5];
>> arr.popFront(); // popFront takes arr by ref
>
> Unless it was ignored for UFCS, which is reasonable, since foo.bar()
> looks like it could modify foo whereas bar(foo) doesn't in general.

Agreed.

--
- Alex
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home