http://d.puremagic.com/issues/show_bug.cgi?id=6442



--- Comment #10 from wfunction@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6442



--- Comment #11 from bearophile_hugs@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6442



--- Comment #12 from wfunction@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6442



--- Comment #13 from Jonathan M Davis <jmdavisProg@gmx.com> 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 (wfunction@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6442



--- Comment #14 from wfunction@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6442



--- Comment #15 from wfunction@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6442



--- Comment #16 from Jonathan M Davis <jmdavisProg@gmx.com> 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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6442



--- Comment #17 from wfunction@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6442



--- Comment #18 from Jonathan M Davis <jmdavisProg@gmx.com> 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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6442



--- Comment #19 from wfunction@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: -------