www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 6442] New: Allow for passing values with the 'ref' keyword

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442

           Summary: Allow for passing values with the 'ref' keyword
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: wfunction hotmail.com



It would be AWESOME if you could pass by-ref parameters using the ref keyword
(ditto with 'out'):


    void foo(ref int bar) { ... }
    int i = 0;
    foo(ref i);   // <------- here

and

    void foo(out int bar) { ... }
    int i = 0;
    foo(out i);   // <------- here


This should be an _optional_ feature, to avoid breaking code and to aide with
generics (saying 'ref' should, however, REQUIRE that the parameter be passed by
ref).

Why?

Documentation.

It documents the fact that you're passing something by reference, avoids bugs
where the variable is changed to be passed by value and the caller's code no
longer works, and making it optional allows everything to still work as before.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 06 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc




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: -------
Aug 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442




"Proof"?

Idk, do you want me to find an example of something that actually broke because
of this?


allows this in COM) so asking "proof" is a little too much, IMHO... it's hard


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: -------
Aug 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442






 "Proof"?
 
 Idk, do you want me to find an example of something that actually broke because
 of this?
 

 allows this in COM) so asking "proof" is a little too much, IMHO... it's hard

 
 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

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: -------
Aug 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442








 "Proof"?
 
 Idk, do you want me to find an example of something that actually broke because
 of this?
 

 allows this in COM) so asking "proof" is a little too much, IMHO... it's hard

 
 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

 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: -------
Aug 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmx.com



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: -------
Aug 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442





 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.


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: -------
Aug 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442




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: -------
Aug 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442





 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: -------
Aug 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442





 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: -------
Aug 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442





 - 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: -------
Aug 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442







 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: -------
Aug 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442





 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: -------
Aug 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442




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: -------
Aug 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442





 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: -------
Aug 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442




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: -------
Aug 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442




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: -------
Aug 07 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442





 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: -------
Aug 07 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442




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: -------
Aug 07 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442





 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: -------
Aug 07 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442




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: -------
Aug 07 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442




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: -------
Aug 07 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442




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



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: -------
Aug 07 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6442




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: -------
Aug 07 2011