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)" 
which assigns 42 to 'number', now lets look at C# code first:

----------- C# code -------------
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 
functions if it doesnt have ref keyword like in C#, i don't ask 
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 "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
prev sibling next sibling parent 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)"
 which assigns 42 to 'number', now lets look at C# code first:

 ----------- C# code -------------
 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
 functions if it doesnt have ref keyword like in C#, i don't ask
 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
prev sibling next sibling parent "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
prev sibling next sibling 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 "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 "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
prev sibling next sibling 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:
Coming from C#, I definitely agree that non-const ref/out 
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