On Friday, 1 June 2012 at 15:58:04 UTC, Andrej Mitrovic wrote:
> On 5/31/12, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>> 2. Just because ref is often better than a pointer doesn't mean that it's
>> never valuable to be able to pass a pointer to a variable.
>
> 5. And '&' documents code better at the call site. I personally refuse
> to use out/ref arguments because the call site makes it ambiguous
> whether an argument is passed by reference or not.

As someone which used to breath Turbo Pascal and Delphi, I really enjoy the C# and C++ references.

Never got the point with C only developers insisting take the address on the call site. This is also one of the features I dislike in Go and should be taken by the compiler in the presence of ref/var/& parameters.

On 06/01/12 23:42, Jonathan M Davis wrote:
> On Friday, June 01, 2012 22:18:19 Artur Skawina wrote:
>>> auto ref is _completely_ different from ref. The compiler chooses whether to pass by ref or not with the idea that it will pick whatever is most efficient for that type, but it's implementation-dependent whether something will be passed by ref or not. And using ref is no solution, because then _all_ of the arguments must be lvalues. If you want a function to take an arbitrary set of arguments where some of them are passed by ref and others not, you _can't do it_. You have to use pointers instead, because the types of all of the parameters are inferred from the arguments, and nothing ever gets inferred as ref, because ref is not a type constructor.
>>
>> I only used "auto ref" so that nobody would complain that it fails for non-lvalues. You can use just 'ref', and i'd agree that such an interface would be saner.
>>
>> However, if you know of a case where 'auto ref' behaves as you describe, file it as a bug. That's not how it's defined, and that is not how it could be sanely implemented. The sane definition is 'if it's an lvalue then it's a ref parameter'. And if you go and check http://dlang.org/template.html you will see it's defined exactly like that. Really, the compiler *cannot* decide by itself if something is passed by value or not, it would make this feature unusable.
> 
> As the feature was proposed, it was up to the compiler to decide whether something was passed by lvalue or rvalue, it was supposed to choose whichever was most efficient. If Walter made it more specific than that (as the docs would indicate), then he's defined it more thoroughly, for better or worse.

I've never had to use 'auto ref' and did not even bother to check that page before writing my first reply - that's how insane any other interpretation would be; it really cannot work any other way. (unless the arguments type has an attribute specifying ref or value semantics, but D does not have those yet)


> But tt doesn't really matter. getopt can't be implemented using auto ref regardless of how defined it is what's ref and not. It uses compile-time reflection to examine the arguments and determine what they're for. Even passing a flag as an lvalue would then make it a ref, making it look like it was supposed to be taking an argument rather than being the string for the flag. By taking pointers, it's explicit, and it works. That won't work with

I'm probably the last person anyone could suspect of having pointerphobia... :)
And using explicit pointers instead of refs as part of an interface is a
good thing, usually much better than (ab)using refs for this. That doesn't
mean however that it cannot be done. So, what is the problem with this 'flag'?
AFAICS (never looked at the getopt code) it always receives the arguments
in pairs, where only the second value needs to be a lvalue. (getopt options can
be skipped over, and can not appear in between). Where is the problem?
The fact that option strings could be passed by ref is harmless.

artur

On Saturday, June 02, 2012 00:23:44 Artur Skawina wrote:
> I've never had to use 'auto ref' and did not even bother to check that page before writing my first reply - that's how insane any other interpretation would be; it really cannot work any other way. (unless the arguments type has an attribute specifying ref or value semantics, but D does not have those yet)

Since the whole purpose of introducing auto ref was to do more or less what const ref does in C++ and try and pass stuff efficiently without caring whether it was an lvalue or rvalue, I'm not sure that it matters much, though arguably, the fact that it doesn't automatically make it all const would make that less sane. Though honestly, given that auto ref can only work with templates, I'd argue that it's pretty much a failure as far as its mandate goes.

> > But tt doesn't really matter. getopt can't be implemented using auto ref regardless of how defined it is what's ref and not. It uses compile-time reflection to examine the arguments and determine what they're for. Even passing a flag as an lvalue would then make it a ref, making it look like it was supposed to be taking an argument rather than being the string for the flag. By taking pointers, it's explicit, and it works. That won't work with
> I'm probably the last person anyone could suspect of having pointerphobia... :) And using explicit pointers instead of refs as part of an interface is a good thing, usually much better than (ab)using refs for this.

I was paying enough attention to who I was responding to. The OP seems to be very against &.

> That doesn't
> mean however that it cannot be done. So, what is the problem with this
> 'flag'? AFAICS (never looked at the getopt code) it always receives the
> arguments in pairs, where only the second value needs to be a lvalue.
> (getopt options can be skipped over, and can not appear in between). Where
> is the problem? The fact that option strings could be passed by ref is
> harmless.

If you specifically watch for the getopt options and compile-time reflection properly flags as that enum type and nothing else as that enum type (I'm not quite sure where that stands, given how enums can't always seem to decide whether they're enums or not), then it may be possible to make getopt work based purely on positioning (it's been a while since I looked at the code, so I don't know quite what it's doing). But it's impossible to make it work based on type. So, even if you can make getopt work, the general problem of not being able to use ref on some but not all of the arguments to a variadic templates remains. You'd have to add a way to the language to indicate that an argument should be passed by ref - which may not be a bad idea. It would only make sense with templates, since that's the only place that the type is in flux, but it might be worth having. getopt works just fine with pointers though.

- Jonathan M Davis

On Thursday, 31 May 2012 at 12:29:21 UTC, Steven Schveighoffer wrote:
> On Thu, 31 May 2012 08:27:17 -0400, Sandeep Datta <datta.sandeep@gmail.com> wrote:
>
>>>
>>> If we removed the requirement for the ampersand, along with requiring parentheses for non-property functions, code which expected to call the function without parentheses would silently compile, but not do what was intended.
>>
>>
>> Consider this...
>>
>> float handleRequest() {
>>  return 1.0f;
>> }
>>
>> float x = handleRequest; //compilation error
>>
>> or
>>
>> auto x = handleRequest;
>>
>> writefln("%f", x); //compilation error
>
> What about:
>
> handleRequest;

That doesn't compile now, if handleRequest is a function pointer (or any other variable):

   Error: var has no effect in expression (handleRequest)

A much bigger problem is implicit conversions to bool, which are used everywhere:

  if (handleRequest) { ... }
  assert (handleRequest);

Now, they test the result of handleRequest.  After the proposed change they test the function pointer.

If this change were to happen we'd need a loooong period between parentheses becoming mandatory for non-properties and dropping the & operator.  We're talking years here.  It's totally not worth it.

-Lars

On Friday, 1 June 2012 at 17:07:57 UTC, Sandeep Datta wrote:
>> I would add that "fptr = &function;" makes it _clear_ what is going on
>> there, otherwise I would have to go and find what "function" is...
>
> There are two contradictory issues at work here which need to be balanced with each other...
>
> 1. While writing code we expect the compiler to understand what we want to do without writing a lot of code. Compiler inference is a boon here. D has some features supporting this (like auto).
>
> 2. While reading code and while trying to reason about the program we want the program to be self documenting and simple. Often as is the case with natural languages some redundancy is required to accomplish this. This makes a language verbose and increases the difficulty / effort required for writing programs.
>
> We don't have many tools which can help us with item #1 but we do have tools which can help significantly with item #2 (eg. IDEs, static code analyzers etc) so IMHO we should design our languages to help us with item #1.
>
> Removing the ampersand is one small step in this direction. Though I agree upfront I have not mastered all the nuances of D to even know if this is possible at all at this point of time.

Wrong. Preferring #1 over #2 completely ignores real life usage.
What actually happens is that we read code more often than writing it (orders of magnitude more) and we also read other people's code as well. Obviouisly we only write our own code.

This raises nightmares of my time as a junior developer maintaining code written by some morrons that decided to name functions with 4-letter abbreviations without any form of documentation what so ever. While I'm sure the original code was very clever and made perfect sense to those original developers and those abreviations were trivially obvious to them, it certainly has no meaning whatsoever to a new guy 30 years later.

So no, prefering ease of writing over ease of reading is a STUPID MORONIC WRONG idea. In fact, all those fancy modern tools such as IDEs help write more readable code by auto-completeing long function names, aleviating the need to used criptic abreviations for faster writing sake.

/rant

Regarding the specific issue of the & - I think that it's a little more consistent to not have it but given the technical issues raised by others it ain't worth it at this time.