W dniu 16.04.2013 17:22, Andrei Alexandrescu pisze:
There's a discussion that may be of interest to the larger community:
https://github.com/D-Programming-Language/dmd/pull/1877
On demand inference FTW!
void fn() auto {
...
}
auto fn() auto {
...
}
On Wednesday, 17 April 2013 at 07:04:16 UTC, Peter Alexander
wrote:
Often enough. I often find myself returning ranges, which are
almost invariably complex template types.
And, to be honest, I would just like to use auto without being
locked into inferred attributes. It just feels wrong that
On Wednesday, 17 April 2013 at 01:55:54 UTC, Jesse Phillips wrote:
On Tuesday, 16 April 2013 at 20:21:00 UTC, Peter Alexander
wrote:
This is the point I have a problem with:
2.2. One cannot opt out of nothrow or pure with auto
functions.
This argument has one solid answer: don't use auto
On Wednesday, 17 April 2013 at 05:55:07 UTC, Walter Bright wrote:
On 4/16/2013 10:31 PM, deadalnix wrote:
On Wednesday, 17 April 2013 at 04:44:59 UTC, Walter Bright
wrote:
BTW, I think we can do attribute inference for all private
functions, too.
Don't this risk to conflict with LTO ?
How s
On 4/16/2013 10:31 PM, deadalnix wrote:
On Wednesday, 17 April 2013 at 04:44:59 UTC, Walter Bright wrote:
BTW, I think we can do attribute inference for all private functions, too.
Don't this risk to conflict with LTO ?
How so?
On Wednesday, 17 April 2013 at 04:44:59 UTC, Walter Bright wrote:
On 4/16/2013 7:30 PM, deadalnix wrote:
I agree with you, I know it may
sound hard to believe, but it had to happen one day :D
I'll mark it on my calendar!
BTW, I think we can do attribute inference for all private
functions, t
On 4/16/2013 7:30 PM, deadalnix wrote:
I agree with you, I know it may
sound hard to believe, but it had to happen one day :D
I'll mark it on my calendar!
BTW, I think we can do attribute inference for all private functions, too.
enience to those who use separate compilation.
I don't view this as an inconsistency, but definitely a change to
why one might choose to use auto.
I'm pretty much for this change. However, I also think it would
be good to introduce attributes to specify a throwing function as
it
On Wednesday, 17 April 2013 at 02:22:31 UTC, Walter Bright wrote:
On 4/16/2013 7:01 PM, deadalnix wrote:
On Tuesday, 16 April 2013 at 15:22:56 UTC, Andrei Alexandrescu
wrote:
There's a discussion that may be of interest to the larger
community:
https://github.com/D-Programming-Language/dmd/pul
On 4/16/2013 7:01 PM, deadalnix wrote:
On Tuesday, 16 April 2013 at 15:22:56 UTC, Andrei Alexandrescu wrote:
There's a discussion that may be of interest to the larger community:
https://github.com/D-Programming-Language/dmd/pull/1877
Andrei
Oh Yes, Yes, Yes, god Yes !
Yes, Yes, Yes !
Ho Yes
On Tuesday, 16 April 2013 at 21:40:18 UTC, Timon Gehr wrote:
I think inferring the return type and inferring the attributes
are mostly orthogonal concerns. (and both are unrelated to the
'auto' storage class'.) But since there is precedent for
conflating attribute inferenc
On Tuesday, 16 April 2013 at 15:22:56 UTC, Andrei Alexandrescu
wrote:
There's a discussion that may be of interest to the larger
community:
https://github.com/D-Programming-Language/dmd/pull/1877
Andrei
Oh Yes, Yes, Yes, god Yes !
Yes, Yes, Yes !
Ho Yes !
On Tuesday, 16 April 2013 at 20:21:00 UTC, Peter Alexander wrote:
This is the point I have a problem with:
2.2. One cannot opt out of nothrow or pure with auto
functions.
This argument has one solid answer: don't use auto when the
need is to specify an attribute pattern explicitly.
I
h are unrelated to the 'auto'
storage class'.) But since there is precedent for conflating attribute
inference with required function bodies, it might be fine.
In order not to be hit by Kenji's worst case debug output scenario, use
something like the following:
void dw(
On 04/16/2013 07:06 PM, Dmitry Olshansky wrote:
16-Apr-2013 19:22, Andrei Alexandrescu пишет:
There's a discussion that may be of interest to the larger community:
https://github.com/D-Programming-Language/dmd/pull/1877
Andrei
In the same vane - how about attribute inference for "ordinary" fu
This is the point I have a problem with:
2.2. One cannot opt out of nothrow or pure with auto functions.
This argument has one solid answer: don't use auto when the
need is to specify an attribute pattern explicitly.
I find this unacceptable. Thanks to the proliferation of template
co
making it a template.
Questions are - why are we hell bent on the `auto' return type being a
marker? What are the other good markers out there? Should we pick
anything else for this auto-magic or let the programmer use some
wild-card marker explicitly?
If we let a bunch of arcane rules govern
overs the various points well:
https://github.com/D-Programming-Language/dmd/pull/1877#issuecomment-16403663
Should the first step here be to fix the issue described in 2.1? I agree
with your reasoning that (b) seems a decent solution. We don't want
'auto' function bodies in
There's a discussion that may be of interest to the larger community:
https://github.com/D-Programming-Language/dmd/pull/1877
Andrei
What do you think about this idea:
http://d.puremagic.com/issues/show_bug.cgi?id=9825
On Monday, February 18, 2013 12:10:37 monarch_dodra wrote:
> Am I wrong in my analysis? More importantly, how would this mix
> with DIP 25 (http://wiki.dlang.org/DIP25) ?
I think that auto ref falls in pretty much exactly the same camp that ref
does. It's not really any different
ences, but a quick investigation
showed me that return by auto-ref is horribly broken.
Basically, the only thing it does is check if the very last
value it returns is a ref, but a ref to what? The
possibilities of returning a ref to a local are HUGE. For
example, simple returning the index of a
On Monday, 18 February 2013 at 21:32:13 UTC, Zach the Mystic
wrote:
On Monday, 18 February 2013 at 11:10:38 UTC, monarch_dodra
wrote:
I think I'm opening a can of worms here, in regards to
inferring the escape of references, but a quick investigation
showed me that return by auto-r
On Monday, 18 February 2013 at 11:10:38 UTC, monarch_dodra wrote:
I think I'm opening a can of worms here, in regards to
inferring the escape of references, but a quick investigation
showed me that return by auto-ref is horribly broken.
Basically, the only thing it does is check if the
I think I'm opening a can of worms here, in regards to inferring
the escape of references, but a quick investigation showed me
that return by auto-ref is horribly broken.
Basically, the only thing it does is check if the very last value
it returns is a ref, but a ref to what
I would suggest that it should work this way, and that maybe
this should be part of the new process focus.
This isn't intended to be demanding -- it could be fairly
simple to provide SOME guide to timeframes. For example, with
redmine, you can attach issues to milestones/releases, and give
a
On Saturday, 26 January 2013 at 19:08:20 UTC, Jonathan M Davis
wrote:
On Saturday, January 26, 2013 17:51:23 Namespace wrote:
That's good to know. But can you estimate _when_ it will be
implemented or with which version? That would be very
informative.
Things generally just don't work that wa
On Sunday, 27 January 2013 at 14:54:26 UTC, Namespace wrote:
On Sunday, 27 January 2013 at 10:35:34 UTC, Namespace wrote:
I didn't know. I thought auto ref would be the only solutions
for non-template functions.
But then I think we must wait for 2 or 3 versions. With this
background know
And before I forget, can I also suggest a syntax?
I would love 'ref&'. ;) It's pretty short and smart.
On Sunday, 27 January 2013 at 10:35:34 UTC, Namespace wrote:
I didn't know. I thought auto ref would be the only solutions
for non-template functions.
But then I think we must wait for 2 or 3 versions. With this
background knowledge I will write my code twice, with and
without ref. Than
On 1/27/13 9:30 AM, deadalnix wrote:
On Sunday, 27 January 2013 at 14:09:17 UTC, Andrei Alexandrescu wrote:
On 1/27/13 8:05 AM, deadalnix wrote:
It seems here that captures provide you a new copy every time. why not
after all ? What is the problem here ?
The property, which is intended to beh
On Sunday, 27 January 2013 at 14:09:17 UTC, Andrei Alexandrescu
wrote:
On 1/27/13 8:05 AM, deadalnix wrote:
It seems here that captures provide you a new copy every time.
why not
after all ? What is the problem here ?
The property, which is intended to behave as a field as much as
possible,
On Sunday, 27 January 2013 at 14:09:17 UTC, Andrei Alexandrescu
wrote:
The property, which is intended to behave as a field as much as
possible, in this case continues to look like a field but
doesn't act like one. That means that switching transparently
between a field and a property (the holy
On 1/27/13 8:05 AM, deadalnix wrote:
It seems here that captures provide you a new copy every time. why not
after all ? What is the problem here ?
The property, which is intended to behave as a field as much as
possible, in this case continues to look like a field but doesn't act
like one. Th
lValues, then
passing off
the temporaries. The temporaries to work right likely need to
be at the
top-most scope of whatever function you happen to be in;
Beyond that I'm
not sure how else the auto ref could be implemented safely.
One simple matter that has been discussed here, which I&#
likely need to be at the
top-most scope of whatever function you happen to be in; Beyond that I'm
not sure how else the auto ref could be implemented safely.
One simple matter that has been discussed here, which I've hit only
yesterday in a script was:
string lines;
...
auto r = regex(
I didn't know. I thought auto ref would be the only solutions for
non-template functions.
But then I think we must wait for 2 or 3 versions. With this
background knowledge I will write my code twice, with and without
ref. Thank you.
On Sunday, January 27, 2013 10:47:42 Namespace wrote:
> Ehh, so if auto ref won't be the solution, we then have auto ref
> for template functions and another solution for non-ref
> functions? I don't think that that is a smart idea and that it
> would be a kind of inconsiste
But it may not even end up being the case that using auto ref
on non-templated
functions is the solution. It may end up being something else
entirely.
Ignoring @safety issues, it seems to me like it would be the
most
straightforward solution, but there are @safety issues with ref
in general
On Sunday, January 27, 2013 07:28:24 deadalnix wrote:
> Back on the point, quoting « Having ref accept rValues seems like
> a bad idea. ». D accepted it for ages, some language accept it by
> design (java for instance).
>
> Now can someone show me the code ?
D's ref has never accepted rvalues. Ra
allowed, but more
likely temporaries will be made for convertion from rValues
to lValues, then passing off the temporaries. The temporaries
to work right likely need to be at the top-most scope of
whatever function you happen to be in; Beyond that I'm not
sure how else the auto ref cou
rValues to
lValues, then passing off the temporaries. The temporaries to
work right likely need to be at the top-most scope of whatever
function you happen to be in; Beyond that I'm not sure how
else the auto ref could be implemented safely.
I have yet to see an instance of such probl
temporaries to
work right likely need to be at the top-most scope of whatever
function you happen to be in; Beyond that I'm not sure how else
the auto ref could be implemented safely.
I have yet to see an instance of such problem in real life, but
quite frankly, I tired to argue.
On 01/26/2013 03:03 AM, Namespace wrote:
> with dmd 2.061 structs aren't lvalues anymore.
You mean, temporary struct objects are not lvalues anymore.
Ali
On Sunday, 27 January 2013 at 01:23:18 UTC, Jonathan M Davis
wrote:
But it may not even end up being the case that using auto ref
on non-templated functions is the solution. It may end up being
something else entirely. Ignoring @safety issues, it seems to
me like it would be the most
On Sunday, January 27, 2013 01:32:07 Namespace wrote:
> > If we add a feature as a temporary measure and then remove it
> > later, we're
> > likely to end up breaking code when it's removed.
>
> No, as far as I can see this don't happend. auto ref w
If we add a feature as a temporary measure and then remove it
later, we're
likely to end up breaking code when it's removed.
No, as far as I can see this don't happend. auto ref works
currently very well for template functions and the pull I suggest
adds the same functiona
.
>
> Another proposal, that I've suggested in another thread, would be
> to merge some "placeholder" pull which fix the problem until the
> official solution is implemented. I thought about this pull:
> https://github.com/D-Programming-Language/dmd/pull/1428
> It
dy for merging and usage. This pull adds functionality
for non-template auto refs but it doesn't change the (template)
auto ref functionality in general, as Kenjis pull does.
On Saturday, January 26, 2013 17:51:23 Namespace wrote:
> That's good to know. But can you estimate _when_ it will be
> implemented or with which version? That would be very informative.
Things generally just don't work that way around here. They get done when they
get done. And often some of the
-knnghuzbzqddaqcjtvch:40forum.dlang.org
I hereby open up again the discussion about auto ref.
There are only some questions: Will auto ref be implemented
in the near
future or not?
Yes. We are actively looking into a complete solution. Along
the way we also very strongly want to define semantics of
"re
about auto ref.
There are only some questions: Will auto ref be implemented in
the near
future or not?
Yes. We are actively looking into a complete solution. Along
the way we also very strongly want to define semantics of "ref"
in such a way that makes unsafe escapes impossible.
Yes. We are actively looking into a complete solution. Along
the way we also very strongly want to define semantics of "ref"
in such a way that makes unsafe escapes impossible. These two
features are related.
Andrei
That's good to know. But can you estimate _when_ it will be
implemented or
No response probably means "you get no official statement"? ;)
if a function's argument is const ref, what would be the problem
of allowing it to to be passed const ref lvalues + rvalues?
On Wednesday, 26 December 2012 at 22:52:29 UTC, Jonathan M Davis
wrote:
On Wednesday, December 26, 2012 23:02:25 deadalnix wrote:
Sound like the way to go for me. But is auto ref needed in such
case ? Why not simply allow ref to behave that way ?
Because there's a very large diffe
"Can we simply make it so that the compiler automatically
creates a variable when you pass an rvalue to a non-templated
auto ref function?"
So non-template auto ref parameters are just like ref
parameters, except they will automatically convert rvalues to
lvalues on call by creati
n order to avoid a copy. It never makes sense
to take an
rvalue by ref. rvalue arguments need to use moves, not ref.
I have read this argument many any times, but still have to
experience it in actual code.
But, thinking about it, isn't the need for an auto ref type
necessary more th
argument by ref in order to mutate that argument and possibly taking an
argument by ref in order to avoid a copy. It never makes sense to take an
rvalue by ref. rvalue arguments need to use moves, not ref.
The suggestion of creating a variable with limited scope which rvalues are
assigned to with
g literals to it in spite of the fact
that it takes
its argument by ref and needs to mutate its argument.
That is a const bug not a ref bug.
With auto ref, you're specifically saying that you don't care
whether the
function is given an lvalue or rvalue. You just want it to
avoi
by ref and needs to mutate its argument.
With auto ref, you're specifically saying that you don't care whether the
function is given an lvalue or rvalue. You just want it to avoid unnecessary
copies. That's very different. And auto ref then not only then protects you
from cases of
, Jonathan M
Davis wrote:
And if that doesn't work, can we simply make it so that the
compiler
automatically creates a variable when you pass an rvalue to
a
non-templated
auto ref function?
I don't see any problems with this, but I admittedly haven't
thought
too much about it.
On Tuesday, 25 December 2012 at 14:11:14 UTC, Andrei Alexandrescu
wrote:
On 12/25/12 5:36 AM, Jonathan M Davis wrote:
On Tuesday, December 25, 2012 11:14:40 Namespace wrote:
What does this generate?
auto foo(auto ref S a, auto ref S b, auto ref S c, auto ref S
d) { ... }
16 different
Yes, that does work and is easy to implement.
Andrei
And why isnt it in 2.061? ;)
> On 2012-12-25 15:11, Andrei Alexandrescu wrote:
>> Yes, that does work and is easy to implement.
This also solves the problem of taking the address of the `auto ref`
function or method. Two birds with one stone.
On 2012-12-25 15:11, Andrei Alexandrescu wrote:
Yes, that does work and is easy to implement.
That's also what one needs to do now.
--
/Jacob Carlborg
12/25/2012 6:15 PM, Peter Alexander пишет:
On Tuesday, 25 December 2012 at 14:09:13 UTC, Andrei Alexandrescu wrote:
[snip]
void foo(auto ref S s1,auto ref S s2,...,auto ref s10)
compiler should generate 2^10 versions of function foo.
The compiler will only generate as many versions as
function still seems like it could
work.
Yes, that does work and is easy to implement.
Is there any reason this hasn't been implemented? And why aren't
template auto ref functions implemented like that? It would be a
bit of a shame if auto ref in template functions works
different
, Jonathan M
Davis wrote:
And if that doesn't work, can we simply make it so that the
compiler
automatically creates a variable when you pass an rvalue to
a
non-templated
auto ref function?
I don't see any problems with this, but I admittedly haven't
thought
too much about it.
On 12/25/12 5:36 AM, Jonathan M Davis wrote:
On Tuesday, December 25, 2012 11:14:40 Namespace wrote:
What does this generate?
auto foo(auto ref S a, auto ref S b, auto ref S c, auto ref S
d) { ... }
16 different functions, one for each combination? Sounds like a
bad idea.
In my opinion
it so that the compiler
automatically creates a variable when you pass an rvalue to a
non-templated
auto ref function?
I don't see any problems with this, but I admittedly haven't thought
too much about it.
If there are no problems with this way, then what I want to know is
why the t
On Tuesday, December 25, 2012 11:44:45 Jens Mueller wrote:
> And the solution needs to be non-template based because it needs to work
> with classes? Is that the only reason?
That and if it's not non-templated, it's impossible to have auto ref functions
which hide their implemen
gt;
> > > > wrote:
> > > > > Why can't we simply make auto ref work with non-templated
> > > > > functions by making
> > > > > it automatically generate both the ref and non-ref versions?
> > > > >
> > > >
On Tuesday, December 25, 2012 11:12:43 Jens Mueller wrote:
> Jonathan M Davis wrote:
> > On Tuesday, December 25, 2012 01:56:42 Peter Alexander wrote:
> > > On Monday, 24 December 2012 at 17:40:54 UTC, Jonathan M Davis
> > >
> > > wrote:
> > > >
On Tuesday, December 25, 2012 11:14:40 Namespace wrote:
> > What does this generate?
> >
> > auto foo(auto ref S a, auto ref S b, auto ref S c, auto ref S
> > d) { ... }
> >
> > 16 different functions, one for each combination? Sounds like a
> > bad ide
Jonathan M Davis wrote:
> On Tuesday, December 25, 2012 01:56:42 Peter Alexander wrote:
> > On Monday, 24 December 2012 at 17:40:54 UTC, Jonathan M Davis
> >
> > wrote:
> > > Why can't we simply make auto ref work with non-templated
> > > functions by
What does this generate?
auto foo(auto ref S a, auto ref S b, auto ref S c, auto ref S
d) { ... }
16 different functions, one for each combination? Sounds like a
bad idea.
In my opinion, this should produce only two functions:
#1: auto foo(ref S a, ref S b, ref S c, ref S d) { ... }
#2
On Tuesday, December 25, 2012 01:56:42 Peter Alexander wrote:
> On Monday, 24 December 2012 at 17:40:54 UTC, Jonathan M Davis
>
> wrote:
> > Why can't we simply make auto ref work with non-templated
> > functions by making
> > it automatically generate b
cally creates a variable when you pass an rvalue to a
non-templated
auto ref function?
I don't see any problems with this, but I admittedly haven't
thought too much about it.
If there are no problems with this way, then what I want to
know is why the template version of auto ref was
On Tuesday, 25 December 2012 at 00:56:44 UTC, Peter Alexander
wrote:
On Monday, 24 December 2012 at 17:40:54 UTC, Jonathan M Davis
wrote:
And if that doesn't work, can we simply make it so that the
compiler
automatically creates a variable when you pass an rvalue to a
non-templated
aut
On Monday, 24 December 2012 at 17:40:54 UTC, Jonathan M Davis
wrote:
Why can't we simply make auto ref work with non-templated
functions by making
it automatically generate both the ref and non-ref versions?
[snip]
What problems does this cause? Why haven't we just done this
alrea
If nothing else, it doesn't work for classes, because templated
functions
can't be virtual. Also, it forces you to put the entire
function's
implementation in a .di file if you use .di files, which makes
it untentable for
many of the folks who actually need to use .di files.
We need a solution
On Monday, December 24, 2012 20:43:06 Robert Clipsham wrote:
> Is:
>
> auto foo()(auto ref S e) { /* do stuff */ }
>
> So hard to write?
>
> (It's Christmas Eve, and I can't be bothered giving real
> arguments against right now - I suppose someone else will
On Monday, 24 December 2012 at 17:40:54 UTC, Jonathan M Davis
wrote:
This has probably been discussed before, so someone has
probably already
explained why this is a bad idea, but I can't remember why that
would be, so
I'm going to ask:
Why can't we simply make auto re
This has probably been discussed before, so someone has probably already
explained why this is a bad idea, but I can't remember why that would be, so
I'm going to ask:
Why can't we simply make auto ref work with non-templated functions by making
it automatically generate both
On 2012-12-24 16:09, Jonathan M Davis wrote:
That would be horrible. Do you remember what std.algorithm looked like before
we were able to put auto in the documentation? It scared most everyone who
looked at it. We don't _want_ the actual return type in the docs. auto return
types
On Monday, December 24, 2012 12:07:53 Jacob Carlborg wrote:
> On 2012-12-23 23:16, Jonathan M Davis wrote:
> > But with return types, it affects the documentation and people's ability
> > to
> > figure out what a function does, so as useful as auto return types ca
On 2012-12-23 23:16, Jonathan M Davis wrote:
But with return types, it affects the documentation and people's ability to
figure out what a function does, so as useful as auto return types can be, they
come with a definite cost and should be avoided if they're not needed.
The compi
If a type of a variable changes don't you want to *know* the
new type of the variable?
Actually, not at all.
Consider this C++ code as an example:
std::vector foo;
template
void process(T &data) { ... }
int test()
{
auto copy = foo;
process(copy);
if (
On 12/23/12 9:13 PM, Peter Alexander wrote:
On Sunday, 23 December 2012 at 22:41:56 UTC, Andrej Mitrovic wrote:
You say auto helps with refactoring. I say not using it helps with
catching bugs. It comes down to a question of what you value more,
your time while coding, or your time while
On Sunday, 23 December 2012 at 22:41:56 UTC, Andrej Mitrovic
wrote:
You say auto helps with refactoring. I say not using it helps
with
catching bugs. It comes down to a question of what you value
more,
your time while coding, or your time while debugging.
Or even just reading code, which is
On Monday, December 24, 2012 00:12:47 Benjamin Thaut wrote:
> Yes this is it. So should I know go in and change everything back
> to auto?
Feel free to do so.
- Jonathan M Davis
On Sunday, 23 December 2012 at 22:49:16 UTC, Andrei Alexandrescu
wrote:
Is this it?
https://github.com/D-Programming-Language/druntime/pull/368
As a general rule, there should be justification for cases
where auto is not to be used. Auto should be reached for by
default.
Andrei
Yes
On 12/23/12 4:54 PM, Benjamin Thaut wrote:
I just created my first pull request for druntime and there where
multiple commonets to _not_ use auto. I don't quite understand why it
shouldn't be used in library functions. If it should not be used why is
it in the language in the first p
On 12/23/12, Jonathan M Davis wrote:
> It makes refactoring the code much easier and reduces code breakage
> due to type changes.
I don't buy that. If a type of a variable changes don't you want to
*know* the new type of the variable? If between two commits you have:
auto
On Sunday, December 23, 2012 23:21:19 Benjamin Thaut wrote:
> It's always about local variables.
Then I don't agree with Andrej at all. For local variables, in general, I
think that auto should be used unless you actually need to explicitly give the
type. It makes refactoring
On Sunday, 23 December 2012 at 22:16:54 UTC, Jonathan M Davis
wrote:
Yeah. I don't know what they were complaining about in the pull
request, but I
think that Andrej has it right. Basically, when declaring the
return type, if
you need type inference, use auto, but if you don't, the
On Sunday, December 23, 2012 14:16:02 Jonathan M Davis wrote:
> On Sunday, December 23, 2012 23:05:28 Andrej Mitrovic wrote:
> > On 12/23/12, Benjamin Thaut wrote:
> > > I just created my first pull request for druntime and there where
> > > multiple commonets to _n
On Sunday, December 23, 2012 23:05:28 Andrej Mitrovic wrote:
> On 12/23/12, Benjamin Thaut wrote:
> > I just created my first pull request for druntime and there where
> > multiple commonets to _not_ use auto. I don't quite understand
> > why it shouldn't be u
On 12/23/12, Benjamin Thaut wrote:
> I just created my first pull request for druntime and there where
> multiple commonets to _not_ use auto. I don't quite understand
> why it shouldn't be used in library functions. If it should not
> be used why is it in the langu
501 - 600 of 1018 matches
Mail list logo
