Jump to page: 1 25  
Page
Thread overview
Call site 'ref'
Jan 15, 2012
Johnatan Frakes
Jan 15, 2012
Peter Alexander
Jan 17, 2012
Stewart Gordon
Jan 15, 2012
F i L
Jan 15, 2012
dsimcha
Jan 15, 2012
Peter Alexander
Jan 15, 2012
Robert Jacques
Jan 15, 2012
Peter Alexander
Jan 15, 2012
Tobias Pankrath
Jan 15, 2012
bearophile
Jan 16, 2012
Alvaro
Jan 16, 2012
Robert Jacques
Jan 15, 2012
bearophile
Jan 15, 2012
Mehrdad
Jan 15, 2012
Nick Sabalausky
Jan 15, 2012
Timon Gehr
Jan 15, 2012
Timon Gehr
Jan 15, 2012
Peter Alexander
Jan 15, 2012
Timon Gehr
Jan 15, 2012
Timon Gehr
Jan 15, 2012
Peter Alexander
Jan 15, 2012
Timon Gehr
Jan 15, 2012
Jonathan M Davis
Jan 16, 2012
Peter Alexander
Jan 16, 2012
Timon Gehr
Jan 16, 2012
Timon Gehr
Jan 16, 2012
Timon Gehr
Jan 18, 2012
Timon Gehr
Jan 16, 2012
Peter Alexander
Jan 15, 2012
Timon Gehr
Jan 16, 2012
Jonathan M Davis
Jan 16, 2012
Mail Mantis
Jan 16, 2012
Timon Gehr
Jan 17, 2012
Mehrdad
Jan 17, 2012
Mail Mantis
January 15, 2012
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
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
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
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
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
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
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
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
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
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