But it works already for templates.
So if it's confusing, then, why was it introduced?
On Fri, 15 Mar 2013 12:32:35 -0400, Namespace
wrote:
But it works already for templates.
So if it's confusing, then, why was it introduced?
The way it works for templates is to generate two separate functions, one
which takes ref and one which takes by value.
The proposed auto ref would
And it is planned to change the functionality of 'auto ref' to
the proposed variant of Jonathan? Or was his proposal rejected?
On Fri, 15 Mar 2013 13:15:21 -0400, Namespace
wrote:
And it is planned to change the functionality of 'auto ref' to the
proposed variant of Jonathan? Or was his proposal rejected?
I have no idea. All I know is that Jonathan's proposal is really what
Andrei wanted originally.
I think w
On Friday, March 15, 2013 18:15:21 Namespace wrote:
> And it is planned to change the functionality of 'auto ref' to
> the proposed variant of Jonathan? Or was his proposal rejected?
I don't think that there was any official decision of any kind. IIRC, Kenji was
looking into at one point and didn
So first of all we have to find a new syntax/name?
AFAIK Kenji made a pull request for a new implementation of
'auto ref' a few months ago. If that was already in the proposed
manner of Jonathan, we need not to discuss with Walter, because
the pull is open for months.
Basically, someone needs to implement it and then talk Walter
into accepting
it. That'll be easier for someone like Kenji, who's already a
major
contributor, but in theory, anyone can do it.
Are there any tutorials or something similar, which make you a
bit familiar with the compiler front-en
On Saturday, March 16, 2013 14:41:37 Namespace wrote:
> > Basically, someone needs to implement it and then talk Walter
> > into accepting
> > it. That'll be easier for someone like Kenji, who's already a
> > major
> > contributor, but in theory, anyone can do it.
>
> Are there any tutorials or so
The only thing I'm aware of which explains anything about the
compiler outside
of the compiler's code itself is this page here:
http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide
- Jonathan M Davis
Alright, It seems as if my knowledge is too limited to somehow
contribute to a solution.^^
Basically, someone needs to implement it and then talk Walter
into accepting
it. That'll be easier for someone like Kenji, who's already a
major
contributor, but in theory, anyone can do it. It's just that
there's a high
risk that the pull request would languish for a while. And it
would probab
On Monday, March 25, 2013 20:43:29 Namespace wrote:
> > Basically, someone needs to implement it and then talk Walter
> > into accepting
> > it. That'll be easier for someone like Kenji, who's already a
> > major
> > contributor, but in theory, anyone can do it. It's just that
> > there's a high
>
Because the number of instantiations of the template could grow
exponentially
as the number of auto ref parameters grows. Being able to use
the trick with
the temporary with templated functions could really help reduce
template bloat
when the current meaning of auto ref is not necessary, but tha
On Monday, March 25, 2013 23:35:06 Namespace wrote:
> > Because the number of instantiations of the template could grow
> > exponentially
> > as the number of auto ref parameters grows. Being able to use
> > the trick with
> > the temporary with templated functions could really help reduce
> > temp
I appreciate your efforts and look forward to the link. :)
But I never heard anything about that. How long has it been since
that was suggested?
But that's honestly sad to hear. I thought I would contribute to
the solution of this problem. Then we'll have to wait and
continue to hope.
Forgot to ask:
Wouldn't it be better to publish this decision?
Many still believe the nonsense (like me) that 'auto ref' is
still the solution.
On Tuesday, March 26, 2013 00:52:56 Namespace wrote:
> Forgot to ask:
> Wouldn't it be better to publish this decision?
> Many still believe the nonsense (like me) that 'auto ref' is
> still the solution.
An official decision would mean that Walter had been involved in it, and that
hasn't happene
You make me curious about this new attribute. Maybe I could then
help to implement this along with its task.
I do not think anyone else has the time to do it.
I hope that you will find the link.
I wonder, if someone has already thought about "immutable ref". I
can not imagine that many use it, so it wouldn't break (much)
code.
On Tuesday, 26 March 2013 at 11:41:13 UTC, Namespace wrote:
I wonder, if someone has already thought about "immutable ref".
I can not imagine that many use it, so it wouldn't break (much)
code.
immutable ref works (for me) very well. Are there any pitfalls
that I can not see?
On Tuesday, March 26, 2013 17:22:29 Namespace wrote:
> On Tuesday, 26 March 2013 at 11:41:13 UTC, Namespace wrote:
> > I wonder, if someone has already thought about "immutable ref".
> > I can not imagine that many use it, so it wouldn't break (much)
> > code.
>
> immutable ref works (for me) very
how about '&' :
void fun(int & x);
which is same as C++ syntax, hence familiar. I thought someone had
proposed that a few weeks ago
On Tue, Mar 26, 2013 at 9:56 AM, Jonathan M Davis wrote:
> On Tuesday, March 26, 2013 17:22:29 Namespace wrote:
>> On Tuesday, 26 March 2013 at 11:41:13 UTC, Names
On Tuesday, March 26, 2013 10:02:32 Timothee Cour wrote:
> how about '&' :
>
> void fun(int & x);
>
> which is same as C++ syntax, hence familiar. I thought someone had
> proposed that a few weeks ago
That would be a much larger change, and I'd be surprised if Walter or Andrei
went for that. Pi
Why is "const ref" not a good choice?
On Tuesday, March 26, 2013 22:55:56 Minas Mina wrote:
> Why is "const ref" not a good choice?
I really don't want to get into that again. There have been a number of
discussions on it in the main newsgroup which you can search for, but Andrei
considers it to be a major mistake of C++ that const&
On Tuesday, March 26, 2013 18:11:42 Jonathan M Davis wrote:
> On Tuesday, March 26, 2013 22:55:56 Minas Mina wrote:
> > Why is "const ref" not a good choice?
>
> I really don't want to get into that again. There have been a number of
> discussions on it in the main newsgroup which you can search f
"Thats the reason why all following declarations behave as const:"
should be
"Thats the reason why all following declarations behave as
const&:"
I tried the last few hours to implement something like 'A&' but
it's horrible if you haven't complete knowledge and want to
implement something that comes after the type...
But what's wrong with '@ref'? If I had knowledge how you could
implement new properties I could start a trial.
Afte
auto in?
in ref?
On Wednesday, 27 March 2013 at 09:10:35 UTC, Minas Mina wrote:
auto in?
in ref?
in ref was suggested by Kenji and rejected by Jonathan.
What should auto in mean? auto const scope?
I have to say that I like ref&, it's the best of two worlds. :)
We need a clear statement so someone can finally b
So I changed it into 'ref&'.
Quick example:
[code]
void bar1(ref& A a) { } // OK
void bar2(ref &A a) { } // OK
void bar21(&A a) { } // Error: '&' can only be used in
combination with 'ref'.
void bar22(& A a) { } // Error: '&' can only be used in
combination with 'ref'.
void bar3(ref const& A
I'm surprised that this is ignored and no one seems to be
interested in a possible solution.
Is it me? Or are my efforts a complete mischief?
Ok I interpret this as a rejection of the idea.
On 29.3.2013 11:59, Namespace wrote:
> Ok I interpret this as a rejection of the idea.
This seems like a language design decision and as such would get much
broader audience (and probably more responses) in digitalmars.D than in
learn forum. Threads in here can get overlooked easily.
Maybe you sh
On Friday, 29 March 2013 at 12:57:55 UTC, Martin Drasar wrote:
On 29.3.2013 11:59, Namespace wrote:
Ok I interpret this as a rejection of the idea.
This seems like a language design decision and as such would
get much
broader audience (and probably more responses) in digitalmars.D
than in
l
34 matches
Mail list logo
