[Issue 6442] Allow for passing values with the 'ref' keyword
https://issues.dlang.org/show_bug.cgi?id=6442 mhh changed: What|Removed |Added Status|NEW |RESOLVED CC||maxha...@gmail.com Resolution|--- |INVALID --- Comment #24 from mhh --- Not really a bug, certainly not in dmd. --
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 --- Comment #23 from bearophile_h...@eml.cc 2011-08-07 13:42:58 PDT --- See also: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=141999 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442
--- Comment #22 from bearophile_h...@eml.cc 2011-08-07 13:30:59 PDT ---
I have a related but alternative proposal; to ask only for the "out" at the
calling point, make it obligatory if you compile with -warning and optional
otherwise (for a long time "override" was like this).
I think having "out" at the calling point is more useful than "ref".
Currently D 2.054 gives no warnings/errors on a program like this (I think the
C# compiler gives something here):
void foo(out int x) {
x = 5;
}
void main() {
int y = 10;
foo(y);
}
The problem here is the initialization of y to 10 always gets ignored.
Assigning something to y, *not using y in any way*, and then using it in a
"out" function argument call, is code smell. It's wasted code at best, and
sometimes it's related to possible semantic bugs.
Using "out" at the calling point doesn't fix that code, but helps the
programmer to see that the assign of 10 to y is useless, and it's better to
remove it:
void foo(out int x) {
x = 5;
}
void main() {
int y = 10;
foo(out y);
}
In my opinion "ref" arguments don't have the same need of being tagged at the
calling point because a function that uses "ref" often reads and writes the
argument (otherwise you use "in" or "out"), so in a ref argument assigning
something to y before the call is more often meaningful:
void foo(ref int x) {
x++;
}
int main() {
int y = 10;
return foo(y);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 --- Comment #21 from wfunct...@hotmail.com 2011-08-07 11:16:43 PDT --- Hmm... /maybe/ I'll try implementing it myself, although I'm not at all familiar with the source code. Let's see how it goes, I'll post here if I get anywhere. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 --- Comment #20 from Jonathan M Davis 2011-08-07 01:12:16 PDT --- Well, I don't think that the feature adds enough of value to be worth adding to the language. But it's not my decision. Discussion on the matter can help influence Walter's decision, but it's ultimately his decision. And at this point, I think that it's pretty much a guarantee that he's not going to add a feature like this any time soon. That doesn't mean that he'd be forever against it, but he's got a lot on his plate right now, and unless a feature solves a real problem in the language which makes doing things hard or impossible, or it fixes a major inconsistency in the language, it's unlikely that Walter would implement it any time soon. He's just too busy, and at this point, most of the work on dmd is going towards stabilizing it and fixing any rough edges on the language itself which need to be fixed for D to be fully usable (one example was the adding of purity inference; without it, pure was essentially useless with templates, so Walter added it). At some point in the future, if he thought that this feature was worth adding he might add it (particularly since it doesn't break backwards compatibility), but it's just not going to happen right now. The only chance that this has of being implemented right now is if someone else implements it and creates a pull request for it. If someone does that, and Walter thinks that the feature is worth having, then it could be added. But if no one else takes the time to implement it, or if Walter doesn't like the feature, and you can't convince him otherwise, it's not going to be implemented any time soon. Unless someone closes this feature request (which isn't likely to happen unless you decide to do it), it'll stick around for quite a while, and maybe Walter will eventually implement it. But you're probably going to have to wait a while. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 --- Comment #19 from wfunct...@hotmail.com 2011-08-07 00:45:04 PDT --- > The fact that it's ref now instead of out has no effect on the calling > function. Yeah it does -- the caller now has to initialize it with something sensible first. Furthermore, the caller is no longer guaranteed that the variable will be initialized _after_ the call -- it could very well remain untouched. If the caller doesn't really care, though, he could omit it altogether -- the benefit of making it optional. The problem with making this required would be that it would mess up templates, auto ref, etc... it just doesn't work for D. But making it optional would let the caller choose whether he wants the easy path or the safe path, without breaking anything. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 --- Comment #18 from Jonathan M Davis 2011-08-07 00:39:42 PDT --- And why would it matter that the function was ref instead of out? It's still affecting the variable that's passed in either case. The fact that it's ref now instead of out has no effect on the calling function. It could change out to ref or ref to out without having any effect on what the function did whatsoever. What _does_ have an effect is that the behavior of the function changed, and it can do that without changing its signature at all. Of bigger import would be if it changed ref or out to non-ref or if it changed non-ref to ref or out. Changing ref or out to non-ref would be caught, but changing non-ref to ref or out wouldn't, because ref and out aren't required at the call site. And yes, assuming that the function's behavior changed when the argument was changed to non-ref, the compiler will have caught it. That is of some value, but since it's so easy to change a function's behavior without changing its signature, and since it's probably fairly rare for a function to change whether it takes an argument by ref or not, it's probably not going to catch much in the way of bugs. It will catch a bug periodically, but given that it gives a false sense of security about what is and isn't actually being passed by ref (since ref and out aren't required at the call site and you really can't know whether an argument wich doesn't have ref or out really is being passed by value or not) and that it's probably not going to catch bugs very often, I'd still argue that it's too minor an advantage to merit changing the language. I think that the feature would be of much more value if it were required, but I _really_ doubt that that would fly at this stage in the game, since it's a breaking change, and while it might be nice to know at a glance whether an argument is being passed by ref or not, I don't think that it's worth being forced to use ref and out every time that you have an argument being passed by ref or out. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 --- Comment #17 from wfunct...@hotmail.com 2011-08-07 00:22:55 PDT --- > const, immutable, shared etc. have a large effect on the semantics of a > program. The compiler gives you additional guarantees as a result. e.g. > immutable variables can't be altered and non-shared can't be affected by > other threads. Right. > However, the situation with your feature request is much different. Wrong. Consider a piece of code like this: bool process(string key, out string value); ... string value; if (process(key, value)) ... Now imagine that, later down the road, I decide to make 'value' actually become a 'ref' parameter, because I want to use its initial value to, for example, set the default value of the environment variable somewhere else, even though I originally only wrote to it. The code that calls process() is broken. Wouldn't it be nice to have an 'out' indicator on 'value', which would give a compile error when the code changes? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 --- Comment #16 from Jonathan M Davis 2011-08-07 00:00:41 PDT --- const, immutable, shared etc. have a large effect on the semantics of a program. The compiler gives you additional guarantees as a result. e.g. immutable variables can't be altered and non-shared can't be affected by other threads. Their effects are quite far-reaching. However, the situation with your feature request is much different. In the current situation with ref and out, the compiler is aware of what can and can't be passed by ref, and won't let you pass something by out or ref if it can't be passed by ref. However, there's no indicator at the call site what is passed by ref and what isn't (which _can_ cause some confusion). If you were required to put ref or out at the call site, that confusion would go away. It wouldn't add any more guarantees to the program whatsoever, since it would have no effect on the semantics of the program, but it would make it clear to the programmer whether a particular function was passing by ref or not (such a feature might or might not be problematic in cases where a function is overloaded on ref). You're effectively forcing documentation of what is and isn't being passed by ref. It would also clutter the code somewhat in that you'd be required to always put ref or out when the function has a ref or out parameter. Whether the benefit of making it explicitly clear what is and isn't being passed by ref or out is worth having to type ref or out every time that an argument is passed by ref is up for debate, and how that interacts with overloads would have to be examined, but there _is_ a clear benefit with such a feature in that it's always clear whether an argument is being passed by ref or out. However, in your suggestion, ref and out are _not_ required at the call site. This has the advantage of not breaking any current code and that those who don't want to use the feature don't have to, but it pretty much negates the value of the feature as well. You have the guaranteed that if an argument in a function call is marked with ref or out that it's being passed by ref or out, but because ref and out are not required at the call site, you don't actually know _anything_ about whether an argument is passed by ref or not when an argument isn't marked with ref or out. So, if you're reading code which uses ref and out on function arguments, you get the false sense of security that it's making it clear what is and isn't being passed by ref, and there's a good chance that you're going to think that any arugments which aren't marked with ref or out are being passed by value, and you're going to misunderstand the code, which is going to lead to mistakes. So, arguably, the situation would be _worse_ than it is right now. You really don't get much more out of it than if you used comments to mark arguments with ref and out. The only benefit that you get is that it checks your "comments" to make sure that the arguments that they're next to are actually passed by ref or out like you claim they are. So, if your feature were _required_, then there would be some definite value in it. Personally, I don't think that it would be worth the extra clutter in the code, but other people may disagree (you obviously do). But if it's not required, then it really doesn't add much more than using comments and is more likely to lead to mistakes IMHO. So, I don't think that it's at all a good idea to add this feature to the language. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 --- Comment #15 from wfunct...@hotmail.com 2011-08-06 23:39:13 PDT --- Er, slight typo copy/pasting your own argument: This: ... are that it's "slightly cleaner" because the comment tokens aren't there, and that the compiler complains if you put ref on an argument which isn't passed by ref. "That's it." should've said: ... are that it's "slightly cleaner" because the comment tokens aren't there, and that the compiler complains if you put change a shared variable in a dangerous way. "That's it." -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 --- Comment #14 from wfunct...@hotmail.com 2011-08-06 23:36:25 PDT --- > The _only_ things that this feature adds over using a comment are that it's > slightly cleaner because the comment tokens aren't there, and > the compiler complains if you put ref on an argument which isn't passed by > ref. > That's it. The "*only*" things? Really? Let me substitute another example into your own phrase. The "only" advantages /*shared(*/ int /*)*/ * p = 5; has over shared(int) * p = 5; are that it's "slightly cleaner" because the comment tokens aren't there, and that the compiler complains if you put ref on an argument which isn't passed by ref. "That's it." So we should scrap away the idea of const/shared too, no? And immutable, and shared, and 'private' members, and 'auto' fields, and 'typeof'... after all, the "only" thing they do is make things more readable and less error-prone, right? How is that any different from 'ref'/'out'? -- Regarding the feature request meta-discussion, Jon: I'm not sure myself if I'm taking it personally or not, but honestly, I'm quite annoyed at the fact that virtually /EVERY/ suggestion I've made about D has had this life cycle: 1. wfunction posts an idea and examples of why it might be useful. 2. Jonathan M. Davis scraps away the idea for the same reason /every/ time: "I can't see why it would possibly be useful." (i.e. any existing language with this feature must therefore be cluttered) 3. wfunction's idea goes in the trash 4. Rinse'n'repeat Seeing this /same/ \exact\ argument throwing my ideas into the trash every time, believe it or not, gets really annoying. Please try to make a distinction between "This is a bad idea because X, Y, and Z make it a **BAD** idea." and "This is a bad idea because I'm not omniscient enough to see how it could be a good idea." Not everyone sees everything, y'know... but you don't have to tell the world about it every time. (Don't forget the first half of this message, btw.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 --- Comment #13 from Jonathan M Davis 2011-08-06 19:47:18 PDT --- A feature needs to add real value to the language to be worth adding. I don't see value in this proposal. Hence why I'm against it. It's as simple as that. The _only_ things that this feature adds over using a comment, e.g. func(/*ref*/ var); are that it's slightly cleaner because the comment tokens aren't there, and the compiler complains if you put ref on an argument which isn't passed by ref. That's it. Due to the fact that it's optional, you can't rely on it at all, because there's no guarantee that the lack of ref on a function argument means that that argument isn't being passed by ref. It seems to me that you (wfunct...@hotmail.com) are taking my dislike for your feature request personally. And I'm sorry if you feel that way (maybe you don't but it at least looks like you do). But that's not how my responses are intended. I'm purely looking at the feature request and what it would or wouldn't add to the language. And I oppose this idea, because I don't think that it really adds anything to the language, and adding it would simply further complicate an already complicated language - not to mention make any code that used it harder to read IMHO. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 --- Comment #12 from wfunct...@hotmail.com 2011-08-06 18:16:24 PDT --- > This is not a competition or a game, it's a conversation :-) > What you have to do is find justifications for adding ref/out at the calling > point, you don't have to find proofs that some other parts of the D language > are useless or badly designed (doing this too is useful, but if you want to > suggest the removal of some D feature, you need to open enhancement requests > for each of them, explain there why, and probably in newsgroup threads too). It looks like you missed my point. I was NOT trying to point out flaws in D. Rather, I was telling /John/ that, unlike his presumption, I _don't_ oppose something simply because I doesn't like it. It had nothing to do with my original argument. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 --- Comment #11 from bearophile_h...@eml.cc 2011-08-06 17:40:46 PDT --- (In reply to comment #10) > OK, fine, you beat me 1 point out of 3. This is not a competition or a game, it's a conversation :-) What you have to do is find justifications for adding ref/out at the calling point, you don't have to find proofs that some other parts of the D language are useless or badly designed (doing this too is useful, but if you want to suggest the removal of some D feature, you need to open enhancement requests for each of them, explain there why, and probably in newsgroup threads too). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 --- Comment #10 from wfunct...@hotmail.com 2011-08-06 17:12:44 PDT --- >> - I don't see a value in "final switch". I don't care that it's there, >> either. > If you switch on an emum, it gives you a nice error if later you add a new > item to the enum. Contrary to your proposal, this is a known source of bugs in C/C++ code. OK, fine, you beat me 1 point out of 3. How about 'with' and '!is null'? Are those also a source of bugs? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 --- Comment #9 from bearophile_h...@eml.cc 2011-08-06 17:03:11 PDT --- > John: It's pretty interesting how you always like the status quo It's the way he is, everyone has the rights to be himself or herself. And ad hominem attacks are out of place in Bugzilla. > - I don't see a value in "final switch". I don't care that it's there, either. If you switch on an emum, it gives you a nice error if later you add a new item to the enum. Contrary to your proposal, this is a known source of bugs in C/C++ code. By the way, I (vaguely) like this proposal, this is why I am commenting here. But to add a feature like this, that has a (small but evident) costs, you must somehow justify it. I agree it's hard to find such "proof". And I think Jonathan is right, making its usage optional is probably going to give troubles. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 --- Comment #8 from wfunct...@hotmail.com 2011-08-06 16:14:57 PDT --- > At this point, changes to the core language are not going to be made without a very good reason, so expect ideas (be they yours or someone else's) to have to add something significant to the language, or they're not likely to be accepted. Right. That part makes 100% sense. But that's nothing like the arguments you've used against my ideas. The part that doesn't make any sense is the "I don't see a point in it" or the "it clutters the language" argument... > As for whether I personally see value in a particular feature, _of course_ I'm likely to be against a feature that I see no value in. There's a difference between: "I don't see a value in that feature" versus "I don't see why ANY group of people would value that feature" If NEITHER of those apply, then yes, I argue against it. But if I can see why someone might like a feature (as I'm sure you do, even if you don't like it yourself), then I don't dismiss it simply because I don't like it. > Wouldn't _you_ usually be against a feature that you see no value in? Examples? Here you go: - I don't see a value in "final switch". I don't care that it's there, either. - I don't see a value in "with". I even think it clutters the code. And yet I don't care that it's there, either, because I can see why people (e.g. VB users) would like it. - I ***ABSOLUTELY HATE*** being forced to use "!is null" instead of "!= null" to compare reference types. It doesn't make any sense to me, and IMHO it should be removed from the language tomorrow. But I'm not arguing against it. Why? Because: I can see why people from other languages (VB, Python, etc.) would find it more useful, even though to me it's just plain stupid. So no, I don't argue against something just because I don't like it. There has to be a clear reason why it sucks, rather than "it sucks because it's not technically necessary for the language to be Turing complete, and I don't find it handy". Let me know if you need more examples. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 --- Comment #7 from Jonathan M Davis 2011-08-06 15:56:17 PDT --- At this point, changes to the core language are not going to be made without a very good reason, so expect ideas (be they yours or someone else's) to have to add something significant to the language, or they're not likely to be accepted. And that's the sort of thing that it's very difficult to convince Walter of (who is who you really need to convince). Changes to the core language are going to be rare at this point. Non-breaking changes (such as this one) are more likely to be accepted, but the language definition is supposed to be essentially stable at this point. Generally, the only changes which are going to be made are those which overcome a flaw or corner case in the language which needs to be resolved. So, feel free to propose new ideas, but they have a very high bar to pass before they're going to make it in. And unless you can convince Walter that a feature is worth adding, it's not going to be added no matter how much value other people see in it. As for whether I personally see value in a particular feature, _of course_ I'm likely to be against a feature that I see no value in. Wouldn't _you_ usually be against a feature that you see no value in? Now, that doesn't mean that there is no value in the feature or that it definitively shouldn't be added just because I don't like it. It just means that I'm arguing against it. And in this particular case, I don't think that what your proposing really adds much value. Instead, it clutters code and risks being highly confusing if it's used inconsistently. So, I don't think that the feature should be added. If you can get Walter to agree with you, then it'll probably be added. But unless have solid arguments which quite a few people agree with, you're probably not going to manage that. And even if you do, Walter is hard to convince. So, go ahead and suggest this feature. It may get in. Personally, I'm against it, and I seriously question that Walter would be in favor of it. But good luck. On a side note, any language changes like this will probably have to undergo a fair bit of discussion in the newsgroup before Walter will agree to add it unless it's clearly a major improvement. So, if you really want this feature, you should bring it up in the newsgroup. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 --- Comment #6 from wfunct...@hotmail.com 2011-08-06 15:41:18 PDT --- > This feature improves code readability, but in D you also have "const ref" > that semantically-wise for the caller is not that different from a pass by value. Const ref has nothing to do with this. It's almost always an optimization issue, not a semantic issue. Ref/out is not for optimization: it's for documentation of the code. Considering that D does not even require variables to be initialized, it's at least helpful to be able to say, "Yes, I **DO** expect this variable to get a value after this function returns" at the call site. John: It's pretty interesting how you always like the status quo (or just hate my ideas in general). You've pretty much opposed every /single/ idea I've proposed, arguing that you don't see a point to it, it's not that useful, etc... but honestly, does /every/ programmer have to see a point to /every/ feature in a language in order for that feature to be potentially useful? Unless you can think of a /disadvantage/ here (other than the usual "clutter" argument, which you can blindly apply to any feature in any language for which you don't see a point), the fact that you would never use because you can't think of an advantage doesn't really say anything in itself. It should be obvious that I'm not arguing for D to be a clone of C#. But there ARE good features in C#, mind you -- and documenting ref/out parameters is one of them. It's easy to type (4 letters total, including the space) and it IMMENSELY improves readability (especially since D doesn't even enforce initialization). Sure, you might never use it... and neither do I use "final switch". But does that mean it's a bad idea? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #5 from Jonathan M Davis 2011-08-06 15:02:36 PDT --- While I agree that it can sometimes be confusing whether a function takes a value by ref or by value, I think that it would clutter code to be using ref at the call site like that. It also gives a false sense of security, since if it's not required, you could easily have code which calls functions which take arguments by ref where some of the calls use ref at the call site and some don't, ultimately confusing anyone reading the code, since it would give the impression that those using ref at the call site passed by ref and those that didn't didn't, which wouldn't be true. The only way that this would really make sense, IMHO, is if it were required. And that would cause problems for generic code and for functions which are overloaded on ref or const ref. It would also potentially cause issues with auto ref parameters. So, while this in interesting idea, I think that it's ultimately a bad idea. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 --- Comment #4 from kenn...@gmail.com 2011-08-06 14:46:43 PDT --- (In reply to comment #3) > (In reply to comment #2) > > "Proof"? > > > > Idk, do you want me to find an example of something that actually broke > > because > > of this? > > > > I don't know too many languages that allow this (like you said, C# 4.0 just > > allows this in COM) so asking "proof" is a little too much, IMHO... it's > > hard > > to find broken C# COM-interop code that got fixed _precisely_ because of > > this. > > > > But I can certainly make an example for you, if you so desire... > > In issue 5409 I have asked for another feature that helps to avoid bugs. This > feature request is backed by a large number of similar bugs found in already > written production code. This not a proof, but for me it's enough evidence to > forbid the (!x & y) pattern. > > I'd like something that justifies to add this feature to D, something beyond > just "C# has it, kind of". I know that it's hard to find, but on the other > hand > you are asking something to programmers (it's optional, but it's not hard to > see D shops with coding conventions that ask to always use the ref/out at the > calling point), so the feature must give something back. > > This feature improves code readability, but in D you also have "const ref" > that > semantically-wise for the caller is not that different from a pass by value. (Nitpick: you can't pass an rvalue with const ref in D.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 --- Comment #3 from bearophile_h...@eml.cc 2011-08-06 11:05:05 PDT --- (In reply to comment #2) > "Proof"? > > Idk, do you want me to find an example of something that actually broke > because > of this? > > I don't know too many languages that allow this (like you said, C# 4.0 just > allows this in COM) so asking "proof" is a little too much, IMHO... it's hard > to find broken C# COM-interop code that got fixed _precisely_ because of this. > > But I can certainly make an example for you, if you so desire... In issue 5409 I have asked for another feature that helps to avoid bugs. This feature request is backed by a large number of similar bugs found in already written production code. This not a proof, but for me it's enough evidence to forbid the (!x & y) pattern. I'd like something that justifies to add this feature to D, something beyond just "C# has it, kind of". I know that it's hard to find, but on the other hand you are asking something to programmers (it's optional, but it's not hard to see D shops with coding conventions that ask to always use the ref/out at the calling point), so the feature must give something back. This feature improves code readability, but in D you also have "const ref" that semantically-wise for the caller is not that different from a pass by value. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 --- Comment #2 from wfunct...@hotmail.com 2011-08-06 08:55:09 PDT --- "Proof"? Idk, do you want me to find an example of something that actually broke because of this? I don't know too many languages that allow this (like you said, C# 4.0 just allows this in COM) so asking "proof" is a little too much, IMHO... it's hard to find broken C# COM-interop code that got fixed _precisely_ because of this. But I can certainly make an example for you, if you so desire... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6442] Allow for passing values with the 'ref' keyword
http://d.puremagic.com/issues/show_bug.cgi?id=6442 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2011-08-06 05:44:47 PDT --- C#4 acts almost like this (the usage of ref and out is not optional, unless for COM interoperability). Generally I like features that improve the code reliability. But where is some kind of "proof" that (optional) ref/out at the calling point make the code less bug prone? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
