www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - current "ref" args state.

reply "evilrat" <evilrat666 gmail.com> writes:
as topic says sometimes ref has a 'little' problem now, it is 
unavoidable in some cases and has some readability in code and 
much more...

imagine we have a function "void getMyNumber(ref int number)" 



int someNumber = 3;
MyCoolLibraryClass.getMyNumber(ref someNumber);
------------------------------

ok, it clearly shows where our variable could be changed, now 
look at same D code:

----------- D code -------------
int someNumber = 3;
getMyNumber(someNumber);
assert(someNumber == 42);
------------------------------

wait... what? what does this function? is it using our nice 
variable to do some computation with it? or maybe it is assigned 
something to our varible? and what if we had lot of other 
function calls before this? how to know our variable stay the all 
time we feed it to functions?

now this is the problem, ref arguments isn't that obvious as it 
should be, it is very easy to mess up in code and spent hours to 
see what's going wrong. currently i trying to add /*ref*/ comment 
before passing such variables to functions. we should really 
change this behaviout and add warning when passing ref args to 

to enfoce, but such little tweak would help a lot.

i may overlooked proposals for this case, if any please give a 
link, sorry for possible duplicate topic.
May 19 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
evilrat:


 i may overlooked proposals for this case, if any please give a 
 link, sorry for possible duplicate topic.


This proposal was discussed two or three times in past, it makes 
the D code look a little worse (beside being a breaking change if 
you want require the ref at the calling point). But it also makes 
D code a little less surprising.

As refinement of this idea, some people suggested to require 
"ref" at the calling point only if the reference is mutable.

And what about the "out" function arguments? Don't you want to 
annotate them too at the calling point?

Bye,
bearophile
May 19 2014
parent reply "evilrat" <evilrat666 gmail.com> writes:
On Monday, 19 May 2014 at 09:56:38 UTC, bearophile wrote:

 evilrat:


 i may overlooked proposals for this case, if any please give a 
 link, sorry for possible duplicate topic.


 This proposal was discussed two or three times in past, it 
 makes the D code look a little worse (beside being a breaking 
 change if you want require the ref at the calling point). But 
 it also makes D code a little less surprising.


the idea is just give a warning for ref if not explicitly stated 
so. no code breakage should occur, only i little warning. 
honestly i can't imagine how it makes code look worse, especially 
since this is a keyword it should be really easy visually 
distinctable in editors.


 As refinement of this idea, some people suggested to require 
 "ref" at the calling point only if the reference is mutable.


good point too. though i don't know current behaviour for 
immutable refs.


 And what about the "out" function arguments? Don't you want to 
 annotate them too at the calling point?


ummm... yes i forgot that there is also "out", but isn't it 
working *almost* same way as ref? with "out" we specifically asks 
function to mutate our data for result. if this is real problem 
maybe some other keyword should be added for both cases at once, 
something like "rout" from ref and out?
May 19 2014
parent "Dicebot" <public dicebot.lv> writes:
On Monday, 19 May 2014 at 10:17:17 UTC, evilrat wrote:

 On Monday, 19 May 2014 at 09:56:38 UTC, bearophile wrote:

 evilrat:


 i may overlooked proposals for this case, if any please give 
 a link, sorry for possible duplicate topic.


 This proposal was discussed two or three times in past, it 
 makes the D code look a little worse (beside being a breaking 
 change if you want require the ref at the calling point). But 
 it also makes D code a little less surprising.


 the idea is just give a warning for ref if not explicitly 
 stated so. no code breakage should occur, only i little warning.


There is no such thing as little warning. It is always either 
recognised as an error to be fixed or ignored. There is more time 
to fix the code breakage but essentially it is not different from 
being an error.
May 19 2014
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 19 May 2014 09:34:48 +0000
evilrat via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 as topic says sometimes ref has a 'little' problem now, it is
 unavoidable in some cases and has some readability in code and
 much more...

 imagine we have a function "void getMyNumber(ref int number)"



 int someNumber = 3;
 MyCoolLibraryClass.getMyNumber(ref someNumber);
 ------------------------------

 ok, it clearly shows where our variable could be changed, now
 look at same D code:

 ----------- D code -------------
 int someNumber = 3;
 getMyNumber(someNumber);
 assert(someNumber == 42);
 ------------------------------

 wait... what? what does this function? is it using our nice
 variable to do some computation with it? or maybe it is assigned
 something to our varible? and what if we had lot of other
 function calls before this? how to know our variable stay the all
 time we feed it to functions?

 now this is the problem, ref arguments isn't that obvious as it
 should be, it is very easy to mess up in code and spent hours to
 see what's going wrong. currently i trying to add /*ref*/ comment
 before passing such variables to functions. we should really
 change this behaviout and add warning when passing ref args to

 to enfoce, but such little tweak would help a lot.

 i may overlooked proposals for this case, if any please give a
 link, sorry for possible duplicate topic.


It's been discussed before and shot down. Among other things, making ref at
the call site would break a lot of code, and it wouldn't play well with UFCS
at all. Also, making ref optional at the call site is by far worse than not
having it all, because then the lack of it still tells you absolutely nothing
but gives the false sense of security that it's not being passed by ref. And
we really shouldn't be adding more warnings, since in the grand scheme of
things, a warning is pretty much the same thing as an error, since not only
is it bad practice to leave warnings in your code, but the -w flag makes
warnings into errors anyway.

C++ is in the same situation with regards to its references, and it works
fine. However, folks do often use pointers instead of references in C++ in
order to make it clearer, and you're free to the same in D if you really don't
like having functions which have ref parameters.

I really don't expect that this aspect of D is going to change at this point.

- Jonathan M Davis
May 19 2014
parent "evilrat" <evilrat666 gmail.com> writes:
On Monday, 19 May 2014 at 10:17:16 UTC, Jonathan M Davis via 
Digitalmars-d wrote:

 C++ is in the same situation with regards to its references, 
 and it works
 fine. However, folks do often use pointers instead of 
 references in C++ in
 order to make it clearer, and you're free to the same in D if 
 you really don't
 like having functions which have ref parameters.


sure i can, but lets say we are using some other library written 
in C++, can we change it to pointers there? no.


okay. looks like this comments above is enough to stop 
disscussion and abandon this proposal. fine.
May 19 2014
prev sibling next sibling parent reply "w0rp" <devw0rp gmail.com> writes:
Explicit or implicit pass by reference at the call site is a 
political argument and it is highly subjective. I'm used to the 
current state of affairs (due to coming from C++) and I don't see 
anything wrong with it. If you can't tell from a function's name 
what its going to do with its arguments, something is probably 
wrong. If you aren't using const or immutable until it hurts, 
something is probably wrong.
May 19 2014
parent "evilrat" <evilrat666 gmail.com> writes:
On Monday, 19 May 2014 at 17:26:25 UTC, w0rp wrote:

 Explicit or implicit pass by reference at the call site is a 
 political argument and it is highly subjective. I'm used to the 
 current state of affairs (due to coming from C++) and I don't 
 see anything wrong with it. If you can't tell from a function's 
 name what its going to do with its arguments, something is 
 probably wrong. If you aren't using const or immutable until it 
 hurts, something is probably wrong.


you don't know the actual use case, yet telling me like if it was 
MY fault...

you came from C++, i came from C++, many people here came from 
C++, but let me remind, this is D and not C++ at all. if you like 
shooting yourself in the leg it doesn't means people would like 
it also(in this case people is anyone who just came to D from any 
other language and possibly who knows C++ well)

as i said before, fine, if this isn't subject to change, fine, 
i'll take it, but do will people take it?

p.s. (ritoric question) why people here thinks they're kind of 
special just because they came from C++ ?
May 19 2014
prev sibling parent "Kapps" <opantm2+spam gmail.com> writes:

arguments should have to include a 'ref' or '&' in front, much 
like pointers do. Silent modification of parameters feels odd to 
me for sure. However at this point it's frankly too late to 
change it, as the change is not worth the tremendous amount of 
breakage that it would cause.
May 19 2014