It turns out there already was a pull request that does this:
https://github.com/D-Programming-Language/dmd/pull/1019
If you are going to use code that is not merged yet, then maybe
it's better to use that one (I've closed my pull request).
Maybe you should reopen your pull, we need definitel
On Sunday, 13 January 2013 at 09:50:37 UTC, Namespace wrote:
It turns out there already was a pull request that does this:
https://github.com/D-Programming-Language/dmd/pull/1019
The pull request is still unmerged. Isn't this important enough
or is the pull invalid?
The question is still th
It turns out there already was a pull request that does this:
https://github.com/D-Programming-Language/dmd/pull/1019
The pull request is still unmerged. Isn't this important enough
or is the pull invalid?
On Wednesday, 2 January 2013 at 01:05:09 UTC, Namespace wrote:
Maybe it's best to just make a pull request and let others
inspect the changes and discuss the semantics of auto ref. Or
maybe it would be better to make a thread in digitalmars.D
first?
In my opinion you should do both, thread an
In my opinion you should do both, thread and also pull request.
I thank you again for your work. I'm using it already.
I have opened a pull request now and replied to the thread about
auto ref on digitalmars.D.
Maybe it's best to just make a pull request and let others
inspect the changes and discuss the semantics of auto ref. Or
maybe it would be better to make a thread in digitalmars.D
first?
In my opinion you should do both, thread and also pull request.
I thank you again for your work. I'm using
So it is ready to merge?
I honestly don't know. I don't know enough about the DMD code
base to be confident that there aren't some serious problems with
my changes.
Another problem is that it isn't entirely clear how auto ref is
supposed to work. Should auto ref on templates work as it does
I took over your changes into my current project (which isn't
that small) and it works very well.
On Tuesday, 1 January 2013 at 11:17:36 UTC, jerro wrote:
On Tuesday, 1 January 2013 at 01:10:20 UTC, Namespace wrote:
On Sunday, 30 December 2012 at 16:11:44 UTC, jerro wrote:
On Sunday, 30 December 2012 at 16:00:22 UTC, Namespace wrote:
Just hope for the best. Did you create a pull request?
On Tuesday, 1 January 2013 at 01:10:20 UTC, Namespace wrote:
On Sunday, 30 December 2012 at 16:11:44 UTC, jerro wrote:
On Sunday, 30 December 2012 at 16:00:22 UTC, Namespace wrote:
Just hope for the best. Did you create a pull request?
No. I need to first make it work correctly with const at
On Tuesday, 1 January 2013 at 08:49:29 UTC, Era Scarecrow wrote:
On Monday, 24 December 2012 at 19:09:35 UTC, Jonathan M Davis
wrote:
On Monday, December 24, 2012 20:03:24 monarch_dodra wrote:
Snap. You got me.
It wouldn't matter if the function accepted its argument by
value. You'd still be
On Monday, 24 December 2012 at 19:09:35 UTC, Jonathan M Davis
wrote:
On Monday, December 24, 2012 20:03:24 monarch_dodra wrote:
Snap. You got me.
It wouldn't matter if the function accepted its argument by
value. You'd still be returning a reference to a variable that
doesn't exist anymore.
On Sunday, 30 December 2012 at 16:11:44 UTC, jerro wrote:
On Sunday, 30 December 2012 at 16:00:22 UTC, Namespace wrote:
Just hope for the best. Did you create a pull request?
No. I need to first make it work correctly with const at the
very least.
Sorry if I seem intrusive, but how does it
On Sunday, 30 December 2012 at 16:11:44 UTC, jerro wrote:
On Sunday, 30 December 2012 at 16:00:22 UTC, Namespace wrote:
Just hope for the best. Did you create a pull request?
No. I need to first make it work correctly with const at the
very least.
You should hurry up, it seems that Walter w
On Sunday, 30 December 2012 at 16:00:22 UTC, Namespace wrote:
Just hope for the best. Did you create a pull request?
No. I need to first make it work correctly with const at the very
least.
Just hope for the best. Did you create a pull request?
On Sunday, 30 December 2012 at 13:57:26 UTC, Namespace wrote:
I've played with this a bit today. The code is at
https://github.com/jerro/dmd/tree/auto-ref. I know next to
nothing about DMD, so it could be all kinds of wrong, but it
does at least seem to work.
What do you think should happen i
I've played with this a bit today. The code is at
https://github.com/jerro/dmd/tree/auto-ref. I know next to
nothing about DMD, so it could be all kinds of wrong, but it
does at least seem to work.
What do you think should happen in this case:
void foo(auto ref int a){}
void foo(int a){}
...
I'd love to see this fixed as well, but I can't change reality,
and I have lots
of other stuff that I need to do (much of which is
Phobos-related) and not
enough time to do it, so I'm not going to spend the time
figuring out enough
about the compiler to implement it myself. And the reality of
t
On Saturday, December 29, 2012 19:43:36 Minas Mina wrote:
> So when it will be fixed I will be able to write:
>
> void foo(auto ref Vector3 v);
>
> and it will pass copies or references depending on the situation?
For templated functions, it currently generates either
void foo(ref Vector3 v);
On Saturday, 29 December 2012 at 18:43:37 UTC, Minas Mina wrote:
So when it will be fixed I will be able to write:
void foo(auto ref Vector3 v);
and it will pass copies or references depending on the
situation?
Yes. The compiler generates the function for the specific
situation.
So you hav
So when it will be fixed I will be able to write:
void foo(auto ref Vector3 v);
and it will pass copies or references depending on the situation?
On Friday, December 28, 2012 23:29:38 Namespace wrote:
> Spontaneous question: why was the behavior altered from lvalue to
> rvalue if there is still no replacement with "auto ref" and so a
> lot of code becomes invalid?
> I know of course that the change was necessary, but as long as
> there is no
Spontaneous question: why was the behavior altered from lvalue to
rvalue if there is still no replacement with "auto ref" and so a
lot of code becomes invalid?
I know of course that the change was necessary, but as long as
there is no fix I don't understand such ruthless change.
It meant no off
On Friday, December 28, 2012 22:21:09 Namespace wrote:
> > 2.061 is beta. I think that the chances of it having something
> > like this in it
> > are very close to zero.
> >
> > - Jonathan M Davis
>
> You know how to give a suffering hope. :D
LOL. Yeah, well. It's not like I'm going to lie about
2.061 is beta. I think that the chances of it having something
like this in it
are very close to zero.
- Jonathan M Davis
You know how to give a suffering hope. :D
On Friday, December 28, 2012 13:19:01 Namespace wrote:
> In consideration that Andrei said that the implementation of
> "auto ref" for none-template functions are relatively easy and
> that until now only the first beta of 2.061 came out: How likely
> is it that "auto ref" will implemented in this
I wrote a workaround for me: I implement it in Romulus. So for
these functions:
[code]
void foo(auto ref const Foo f) {
// do something with f
}
const(int[42]) bar(auto ref const Foo a, auto ref const Foo b)
pure nothrow {
// do something with a and b
}
const(int[42]) quatz(a
On Friday, 28 December 2012 at 12:47:03 UTC, Namespace wrote:
On Friday, 28 December 2012 at 12:28:01 UTC, bearophile wrote:
Namespace:
How likely is it that "auto ref" will implemented in this
release?
Walter wants to release 2.061 "soon". So maybe that's for the
successive (unstable?) ver
On Friday, 28 December 2012 at 12:28:01 UTC, bearophile wrote:
Namespace:
How likely is it that "auto ref" will implemented in this
release?
Walter wants to release 2.061 "soon". So maybe that's for the
successive (unstable?) version of the compiler.
Bye,
bearophile
As long as it is impl
Namespace:
How likely is it that "auto ref" will implemented in this
release?
Walter wants to release 2.061 "soon". So maybe that's for the
successive (unstable?) version of the compiler.
Bye,
bearophile
In consideration that Andrei said that the implementation of
"auto ref" for none-template functions are relatively easy and
that until now only the first beta of 2.061 came out: How likely
is it that "auto ref" will implemented in this release? Maybe an
official statement would be good.
Purel
On Wednesday, 26 December 2012 at 22:33:38 UTC, Jonathan M Davis
wrote:
On Wednesday, December 26, 2012 10:43:53 Namespace wrote:
Quick question: what is the state of things with dmd 2.061
AFAIK, it's exactly the same as it was in 2.060.
- Jonathan M Davis
I mean, when it comes out. But tha
On Wednesday, December 26, 2012 10:43:53 Namespace wrote:
> Quick question: what is the state of things with dmd 2.061
AFAIK, it's exactly the same as it was in 2.060.
- Jonathan M Davis
Quick question: what is the state of things with dmd 2.061 and I
see that right, that "auto ref" is more complicated than first
thought? :/
On Monday, December 24, 2012 16:08:36 Andrei Alexandrescu wrote:
> On 12/24/12 1:49 PM, Jonathan M Davis wrote:
> > On Monday, December 24, 2012 13:45:10 Andrei Alexandrescu wrote:
> Actually D's rules are different from C++'s in that regard; Walter
> mentioned D is more sanguine about destroying d
On 12/24/12 2:46 PM, anonymous wrote:
On Monday, 24 December 2012 at 18:50:12 UTC, Jonathan M Davis wrote:
const int& i = foo(bar(min(5, 7)));
which would allow a reference to be kept around, which D disallows.
Does it?
const(int)* i = &foo(bar(min(5, 7)));
We plan to forbid that.
Andrei
On 12/24/12 1:49 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 13:45:10 Andrei Alexandrescu wrote:
The very binding of rvalues to const ref would allow that breakage. We
can't allow that to happen.
But it's only bound for the length of the statement. After that, the binding
can no l
On Monday, December 24, 2012 21:42:09 monarch_dodra wrote:
> Side question, is this legal?
>
> "int a = min(min(1,2), min(3,4));"
>
> How long do those temps last? I like this piece of code, because
> the previous had that fishy "const int&", which raises eyebrows,
> but I think this example coul
On Monday, 24 December 2012 at 19:09:35 UTC, Jonathan M Davis
wrote:
On Monday, December 24, 2012 20:03:24 monarch_dodra wrote:
Hum... Indeed, it takes by ref *and* returns by ref. Passing in
to out a const ref is *the* smoking gun. Working with D has
gotten me used to functions that take by val
On Monday, December 24, 2012 20:46:00 anonymous wrote:
> On Monday, 24 December 2012 at 18:50:12 UTC, Jonathan M Davis
>
> wrote:
> > const int& i = foo(bar(min(5, 7)));
> >
> > which would allow a reference to be kept around, which D
> > disallows.
>
> Does it?
>
> const(int)* i = &foo(bar(min
On Monday, 24 December 2012 at 18:50:12 UTC, Jonathan M Davis
wrote:
const int& i = foo(bar(min(5, 7)));
which would allow a reference to be kept around, which D
disallows.
Does it?
const(int)* i = &foo(bar(min(5, 7)));
On Monday, December 24, 2012 20:03:24 monarch_dodra wrote:
> Hum... Indeed, it takes by ref *and* returns by ref. Passing in
> to out a const ref is *the* smoking gun. Working with D has
> gotten me used to functions that take by value and return by
> value...
>
> Snap. You got me.
It wouldn't ma
On Monday, 24 December 2012 at 18:42:31 UTC, Andrei Alexandrescu
wrote:
On 12/24/12 1:05 PM, monarch_dodra wrote:
On Monday, 24 December 2012 at 17:37:54 UTC, Andrei
Alexandrescu wrote:
On 12/24/12 12:11 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 17:55:23 Minas Mina wrote:
On Sun
On Monday, December 24, 2012 19:05:32 monarch_dodra wrote:
> On Monday, 24 December 2012 at 17:37:54 UTC, Andrei Alexandrescu
> wrote:
> > An important smoking gun is C++'s min(), which is allows
> > writing unsafe code without casts.
> >
> > const int& haveANiceDay = min(4, 5);
> >
> >
> > Andr
On Monday, December 24, 2012 13:45:10 Andrei Alexandrescu wrote:
> The very binding of rvalues to const ref would allow that breakage. We
> can't allow that to happen.
But it's only bound for the length of the statement. After that, the binding
can no longer exist (as the binding was a function p
On 12/24/12 1:20 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 22:11:58 Dmitry Olshansky wrote:
12/24/2012 9:57 PM, Jonathan M Davis пишет:
On Monday, December 24, 2012 12:37:54 Andrei Alexandrescu wrote:
An important smoking gun is C++'s min(), which is allows writing unsafe
code w
On 12/24/12 12:57 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 12:37:54 Andrei Alexandrescu wrote:
An important smoking gun is C++'s min(), which is allows writing unsafe
code without casts.
const int& haveANiceDay = min(4, 5);
But what does that have to do with const& for funct
On 12/24/12 1:05 PM, monarch_dodra wrote:
On Monday, 24 December 2012 at 17:37:54 UTC, Andrei Alexandrescu wrote:
On 12/24/12 12:11 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 17:55:23 Minas Mina wrote:
On Sunday, 23 December 2012 at 23:59:55 UTC, Jonathan M Davis
wrote:
On Mond
On Monday, December 24, 2012 22:11:58 Dmitry Olshansky wrote:
> 12/24/2012 9:57 PM, Jonathan M Davis пишет:
> > On Monday, December 24, 2012 12:37:54 Andrei Alexandrescu wrote:
> >> An important smoking gun is C++'s min(), which is allows writing unsafe
> >> code without casts.
> >>
> >> const int
12/24/2012 9:57 PM, Jonathan M Davis пишет:
On Monday, December 24, 2012 12:37:54 Andrei Alexandrescu wrote:
An important smoking gun is C++'s min(), which is allows writing unsafe
code without casts.
const int& haveANiceDay = min(4, 5);
But what does that have to do with const& for function
On Monday, 24 December 2012 at 17:37:54 UTC, Andrei Alexandrescu
wrote:
On 12/24/12 12:11 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 17:55:23 Minas Mina wrote:
On Sunday, 23 December 2012 at 23:59:55 UTC, Jonathan M Davis
wrote:
On Monday, December 24, 2012 00:48:01 Namespace wr
On Monday, December 24, 2012 12:37:54 Andrei Alexandrescu wrote:
> An important smoking gun is C++'s min(), which is allows writing unsafe
> code without casts.
>
> const int& haveANiceDay = min(4, 5);
But what does that have to do with const& for function parameters? I can agree
that it's bad f
On 12/24/12 12:11 PM, Jonathan M Davis wrote:
On Monday, December 24, 2012 17:55:23 Minas Mina wrote:
On Sunday, 23 December 2012 at 23:59:55 UTC, Jonathan M Davis
wrote:
On Monday, December 24, 2012 00:48:01 Namespace wrote:
but Andrei is dead set against
- Jonathan M Davis
Why?
He's con
On Monday, December 24, 2012 17:55:23 Minas Mina wrote:
> On Sunday, 23 December 2012 at 23:59:55 UTC, Jonathan M Davis
>
> wrote:
> > On Monday, December 24, 2012 00:48:01 Namespace wrote:
> >but Andrei is dead set against
> >
> > - Jonathan M Davis
>
> Why?
He's convinced that it's caused prob
On Sunday, 23 December 2012 at 23:59:55 UTC, Jonathan M Davis
wrote:
On Monday, December 24, 2012 00:48:01 Namespace wrote:
but Andrei is dead set against
- Jonathan M Davis
Why?
On Monday, December 24, 2012 12:16:15 Namespace wrote:
> Put another way: how long will we probably still wait for a
> solution? Yet another release, or 2? Say, 6 months or even
> longer? When it comes in the near future (ie a maximum of 1-2
> months), then it would be sufficient simply to templati
On Monday, December 24, 2012 14:01:10 Namespace wrote:
> One more thing: Which pull request is for "auto ref" for
> none-template functions?
There isn't one.
- Jonathan M Davis
One more thing: Which pull request is for "auto ref" for
none-template functions?
Put another way: how long will we probably still wait for a
solution? Yet another release, or 2? Say, 6 months or even
longer? When it comes in the near future (ie a maximum of 1-2
months), then it would be sufficient simply to templatize my
methods. But if it goes for much longer (which I stro
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 everythi
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 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 c
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 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 actu
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 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
On 12/24/12, Namespace 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.
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 st
69 matches
Mail list logo
