digitalmars.D - current "ref" args state.
- evilrat (30/30) May 19 2014 as topic says sometimes ref has a 'little' problem now, it is
- bearophile (11/13) May 19 2014 This proposal was discussed two or three times in past, it makes
- evilrat (13/24) May 19 2014 the idea is just give a warning for ref if not explicitly stated
- Dicebot (5/17) May 19 2014 There is no such thing as little warning. It is always either
- Jonathan M Davis via Digitalmars-d (17/47) May 19 2014 It's been discussed before and shot down. Among other things, making ref...
- evilrat (6/13) May 19 2014 sure i can, but lets say we are using some other library written
- w0rp (7/7) May 19 2014 Explicit or implicit pass by reference at the call site is a
- evilrat (12/19) May 19 2014 you don't know the actual use case, yet telling me like if it was
- Kapps (6/6) May 19 2014 Coming from C#, I definitely agree that non-const ref/out
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
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
On Monday, 19 May 2014 at 09:56:38 UTC, bearophile wrote:evilrat: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.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.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
"Dicebot" <public dicebot.lv> On Monday, 19 May 2014 at 10:17:17 UTC, evilrat wrote:On Monday, 19 May 2014 at 09:56:38 UTC, bearophile wrote: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.evilrat:the idea is just give a warning for ref if not explicitly stated so. no code breakage should occur, only i little warning.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.
May 19 2014
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
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
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
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
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