As the title says: In dmd 2.061 structs are lvalues now, but we have still no auto ref for none template functions. What should I do if I need something like that and don't want to write a ref and a none-ref function?
I'm very afraid that "auto ref" will also not work in 2.062 So what is the stage of affairs? Or is there any hope that it will be fixed in 2.061?

On 12/24/12, Namespace <rswhite4@googlemail.com> wrote:
> As the title says: In dmd 2.061 structs are lvalues now

You mean struct literals? They're rvalues now, this wasn't enforced before but it is now since a recent pull. Can't answer your other question, sorry.

On Sunday, 23 December 2012 at 23:53:49 UTC, Andrej Mitrovic wrote:
> On 12/24/12, Namespace <rswhite4@googlemail.com> wrote:
>> As the title says: In dmd 2.061 structs are lvalues now
>
> You mean struct literals? They're rvalues now, this wasn't enforced
> before but it is now since a recent pull. Can't answer your other
> question, sorry.

Yes of course. They was lvalues.

On Monday, December 24, 2012 00:48:01 Namespace wrote:
> As the title says: In dmd 2.061 structs are lvalues now, but we
> have still no auto ref for none template functions. What should I
> do if I need something like that and don't want to write a ref
> and a none-ref function?
> I'm very afraid that "auto ref" will also not work in 2.062 So
> what is the stage of affairs? Or is there any hope that it will
> be fixed in 2.061?

If you have a templated function, you can use auto ref. If you have a non- templated function, you need to write both a ref and non-ref function (though the non-ref version can forward to the ref one avoiding having to duplicate the entire function). It's a long-standing issue that has yet to be resolved, and it won't be fixed in 2.061 as we're about to start preparing for that release.

I think that Kenji was working on trying to get auto ref to work with non- templated functions in some manner at one point but ran into issues with it, and it hasn't really been decided what the correct solution is, so I don't know when it will be fixed. Plenty of folks would simply argue for const ref working like it does in C++, but Andrei is dead set against that, so it hasn't happened. It's not necessarily a good fix anyway though given the fact that const is so much more restrictive in D. auto ref will accept both lvalues and rvalues but will allow for the mutation of the argument, making it somewhat different from what you get with const& in C++, but it also avoids having to restrict yourself with const (and you can still use const with auto ref if you want to). So, we may need a similar fix with non-templated functions.

As for struct literals, it never made sense for them to be lvalues. They're temporaries, not variables. And it causes stupidity like

S foo() {...}
auto bar(ref S) {...}

bar(S()); //compiles
bar(foo()); //doesn't compile

There's no question though that the issue with const ref / auto ref needs to be resolved. But unfortunately, that's still an open issue.

- Jonathan M Davis

If I remember correctly, the discussion and the fix of "auto ref" permanently on dmd since 2.058. But since at least June 2012. Is that correct?
That is a very important use case. No one can/will use D seriously if D has all the time such big problems.

On Monday, December 24, 2012 01:19:22 Namespace wrote:
> If I remember correctly, the discussion and the fix of "auto ref" permanently on dmd since 2.058. But since at least June 2012. Is that correct?

It's been discussed off and on for ages, but it's never been a high enough priority to actually get fixed. I believe that the last major discussion involving both Walter and Andrei was on the Beta list during the beta for 2.060, but there have been a couple of discussions involving other people in the main newsgroup more recently than that.

> That is a very important use case. No one can/will use D seriously if D has all the time such big problems.

Plenty of people are using it with the problems that it currently has, but I do agree that it needs to be fixed. Still, it's not like problems aren't being fixed. It's just that other problems have been fixed first.

- Jonathan M Davis

> Plenty of people are using it with the problems that it currently has

But how long?

For the moment (or the next 2, 3 releases) it should be enough if I write
void foo()(auto ref const Foo f) {
instead of
void foo(ref const Foo f) {

or is there any difficulty? After all it's a template now.

On Monday, December 24, 2012 02:41:41 Namespace wrote:
> > Plenty of people are using it with the problems that it currently has
> 
> But how long?
> 
> For the moment (or the next 2, 3 releases) it should be enough if
> I write
> void foo()(auto ref const Foo f) {
> instead of
> void foo(ref const Foo f) {
> 
> or is there any difficulty? After all it's a template now.

If you templatize a function, then you can use auto ref with it, and auto ref functions will work with both lvalues and rvalues without copying either. It basically creates two overloads - a ref and non-ref version. The ref version takes lvalues and obviously won't make copies. The non-ref version _might_ copy but shouldn't, because the compiler will generally move rvalues values rather than copying them.

- Jonathan M Davis

Yes that's what I thought. My question was, if it's bad if now a lot of my functions/methods are templatized.

On Monday, December 24, 2012 09:08:09 Namespace wrote:
> Yes that's what I thought. My question was, if it's bad if now a lot of my functions/methods are templatized.

That would depend on what you're doing. It's a problem with classes, because templated functions can't be virtual. With everything else, it mostly depends on whether you care about the fact that the function won't exist if it's not use and the fact that if you're putting it in a library, it won't really be compiled into the library unless it's actually used in the library (so it won't save you any disk space). Also, it will have to have its full source code in .di files if you use .di files. You also potentially have to put up with a different set of compiler bugs, since some bugs affect templated functions but not non-templated functions (and probably vice versa), which probably isn't much of an issue, but that would depend on whatever bugs there happen to currently be.

So, for the most part, I'd say that it's a non-issue aside from classes, but you might care, depending on what you're doing.

- Jonathan M Davis