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 place?
Kind Regards
Benjamin Thaut
On Friday, 7 December 2012 at 14:21:51 UTC, Nick Treleaven wrote:
On 03/12/2012 14:22, Nick Treleaven wrote:
Most programmers would probably just pollute the existing
scope:
auto x = "thing" in arr;
if (x && *x == 45)
{
...
}
I expect this is because wrapping the abo
On 03/12/2012 14:22, Nick Treleaven wrote:
Most programmers would probably just pollute the existing scope:
auto x = "thing" in arr;
if (x && *x == 45)
{
...
}
I expect this is because wrapping the above in {} for a new scope is
just too ugly, introducing more nesting an
On 03/12/2012 20:17, Rob T wrote:
On Monday, 3 December 2012 at 14:22:28 UTC, Nick Treleaven wrote:
Most programmers would probably just pollute the existing scope:
auto x = "thing" in arr;
if (x && *x == 45)
{
...
}
You can always wrap it inside its own scope
Yes,
On Monday, 3 December 2012 at 14:22:28 UTC, Nick Treleaven wrote:
Most programmers would probably just pollute the existing scope:
auto x = "thing" in arr;
if (x && *x == 45)
{
...
}
You can always wrap it inside its own scope
main()
{
// temp scope
{
auto
On 02/12/2012 15:09, js.mdnq wrote:
Can this be made to work in D?
Error in D, x not found:
if (auto x = "thing" in arr && x == 45)
{
}
Works:
if (auto x = "thing" in arr)
if (x == 45)
{
}
Most programmers would probably just pollute the exis
On Sunday, 2 December 2012 at 15:09:17 UTC, js.mdnq wrote:
Can this be made to work in D?
Error in D, x not found:
if (auto x = "thing" in arr && x == 45)
{
}
You can't have both a declaration and expression in an
if-statement.
http://dlang.org/statement.html#I
And no, it cannot be made to work, because the grammar would be
ambiguous:
if (auto x = y && z)
Does this mean?
if (auto x = (y && z))
or
if (auto x = y)
if (x && z)
You could make it work with new syntax, but given you can just
use two if-statements, I don't see any point.
Can this be made to work in D?
Error in D, x not found:
if (auto x = "thing" in arr && x == 45)
{
}
Works:
if (auto x = "thing" in arr)
if (x == 45)
{
}
I'm not sure who to notify, but I seem to have hung the
unittester on one of my releases:
http://d.puremagic.com/test-results/pull-history.ghtml?repoid=3&pullid=915
Those first 3 tests have been running (as of now) for about 5
hours.
I've tried to get in touch with a couple of people, but th
On Wednesday, 12 September 2012 at 06:09:04 UTC, Alex Rønne
Petersen wrote:
Hi,
I'm currently working on porting the tool chain to Solaris (or
rather, updating the existing, bitrotten port). It would be
nice if we could add a Solaris machine to the auto tester
infrastructure to make sur
Hi,
I'm currently working on porting the tool chain to Solaris (or rather,
updating the existing, bitrotten port). It would be nice if we could add
a Solaris machine to the auto tester infrastructure to make sure the
port doesn't regress.
--
Alex Rønne Petersen
a...@lycu
On 09/11/12 08:21, Mehrdad wrote:
> http://forum.dlang.org/thread/is9jmn$2ia5$1...@digitalmars.com
Completely different issue. That one is about syntax sugar for template
functions, while this one would just save the programmer some typing when
declaring "normal" functions (by propagating the type
On 09/10/12 15:46, Timon Gehr wrote:
> On 09/10/2012 12:34 PM, Artur Skawina wrote:
>> On 09/10/12 06:20, Andrej Mitrovic wrote:
>>> It occurred to me that using a parameter with a default value that is
>>> a function call could benefit from using auto:
>>>
On 9/10/12, Timon Gehr wrote:
> Every type that you can get hold of a value of can be specified by the
> means of typeof.
Yeah but it's repetitive. typeof(exp) arg = exp;
On 09/10/2012 12:34 PM, Artur Skawina wrote:
On 09/10/12 06:20, Andrej Mitrovic wrote:
It occurred to me that using a parameter with a default value that is
a function call could benefit from using auto:
struct Foo(T) { }
auto getFoo()
{
return Foo!int();
}
void func(int x, auto foo
On 09/10/2012 06:20 AM, Andrej Mitrovic wrote:
It occurred to me that using a parameter with a default value that is
a function call could benefit from using auto:
struct Foo(T) { }
auto getFoo()
{
return Foo!int();
}
void func(int x, auto foo = getFoo()) { }
Granted this is a simple
On 09/10/12 06:20, Andrej Mitrovic wrote:
> It occurred to me that using a parameter with a default value that is
> a function call could benefit from using auto:
>
> struct Foo(T) { }
>
> auto getFoo()
> {
> return Foo!int();
> }
>
> void func(int x, auto
It occurred to me that using a parameter with a default value that is
a function call could benefit from using auto:
struct Foo(T) { }
auto getFoo()
{
return Foo!int();
}
void func(int x, auto foo = getFoo()) { }
Granted this is a simple case and might be overkill, but if the
function
On Monday, 13 August 2012 at 19:09:04 UTC, Minas Mina wrote:
Is it a bug with auto or something else?
It's not really a bug. You're using insert before its return type
has been inferred. Hence, it says "forward reference to inferred
return type".
However, in thi
null;
}
else
{
if( val < root.value )
root.left = insert(root.left, val);
else
root.right = insert(root.right, val);
}
return root;
}
This works (compiles).
auto
tems, they are a great structuring force. Which
> is part of why I love D: "auto" and "Variant" lets you forget
> about a lot of it, but you can still be explicit when it is
> important.
As David and Andrei suggest, it would be good to turn this into a blog
post, especial
On 7/27/12 6:25 PM, David Nadlinger wrote:
You might want to turn this into a blog post.
Yes please.
Andrei
yping
(Python/Ruby/Ecmascript). But when thinking about complicated
algorithms and systems, they are a great structuring force.
Which is part of why I love D: "auto" and "Variant" lets you
forget about a lot of it, but you can still be explicit when it
is important.
My two cents,
NMS
d become a pain (e.g.
Java), hence the popularity of dynamic typing
(Python/Ruby/Ecmascript). But when thinking about complicated
algorithms and systems, they are a great structuring force. Which
is part of why I love D: "auto" and "Variant" lets you forget
about a lot of i
you'd like the
> >> compiler to avoid the copy if it can, I don't see why it's restrictive
> >> at all to make>
> > That's not what auto-ref does. We already had this discussion. auto-ref
> > lets
> To clarify - /avoiding a copy/ is not the only,
don't see why it's restrictive at all to make
>
> That's not what auto-ref does. We already had this discussion. auto-ref lets
To clarify - /avoiding a copy/ is not the only, or even the main, use of
this feature. Copy avoidance mostly matters for structs, and these cases
sh
:
>>>>>> On Wednesday, June 27, 2012 07:02:28 Mehrdad wrote:
>>>>>>> On Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis
>>>>>>>
>>>>>>> wrote:
>>>>>>>> And how would that work? auto ref du
gt;>
> >>> wrote:
> >>>> And how would that work? auto ref duplicates the function. If
> >>>> you pass it an lvalue, then it generates a ref version.
> >>>
> >>> Two solutions:
> >>>
> >>> - Turn 'auto
Mehrdad wrote:
> >>>>> On Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis
> >>>>>
> >>>>> wrote:
> >>>>>> And how would that work? auto ref duplicates the function. If
> >>>>>> you pass it a
Artur Skawina:
A new "override ref" could work like you describe.
Introducing yet more modifiers and complexity should be done only
if they are very useful.
Bye,
bearophile
On 06/27/12 07:27, kenji hara wrote:
> 2012/6/27 Jonathan M Davis :
>> On Wednesday, June 27, 2012 07:02:28 Mehrdad wrote:
>>> On Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis
>>>
>>> wrote:
>>>> And how would that work? auto ref duplic
On 06/27/2012 01:12 PM, kenji hara wrote:
2012/6/27 Timon Gehr:
On 06/27/2012 07:27 AM, kenji hara wrote:
2012/6/27 Jonathan M Davis:
On Wednesday, June 27, 2012 07:02:28 Mehrdad wrote:
On Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis
wrote:
And how would that work? auto
2012/6/27 Timon Gehr :
> On 06/27/2012 07:27 AM, kenji hara wrote:
>>
>> 2012/6/27 Jonathan M Davis:
>>>
>>> On Wednesday, June 27, 2012 07:02:28 Mehrdad wrote:
>>>
>>>> On Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis
>>
On 06/27/2012 07:27 AM, kenji hara wrote:
2012/6/27 Jonathan M Davis:
On Wednesday, June 27, 2012 07:02:28 Mehrdad wrote:
On Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis
wrote:
And how would that work? auto ref duplicates the function. If
you pass it an lvalue, then it generates
On Wednesday, June 27, 2012 14:27:08 kenji hara wrote:
> 2012/6/27 Jonathan M Davis :
> > On Wednesday, June 27, 2012 07:02:28 Mehrdad wrote:
> >> On Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis
> >>
> >> wrote:
> >> > And how would
2012/6/27 Jonathan M Davis :
> On Wednesday, June 27, 2012 07:02:28 Mehrdad wrote:
>> On Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis
>>
>> wrote:
>> > And how would that work? auto ref duplicates the function. If
>> > you pass it an lvalue, the
On Wednesday, June 27, 2012 07:02:28 Mehrdad wrote:
> On Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis
>
> wrote:
> > And how would that work? auto ref duplicates the function. If
> > you pass it an lvalue, then it generates a ref version.
>
> Two solut
On Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis
wrote:
And how would that work? auto ref duplicates the function. If
you pass it an lvalue, then it generates a ref version.
Two solutions:
- Turn 'auto ref' into 'ref', but simply have the compiler
generate a
On Wednesday, June 27, 2012 06:03:12 Mehrdad wrote:
> On Wednesday, 27 June 2012 at 03:54:12 UTC, Jonathan M Davis
>
> wrote:
> > That isn't legal. auto ref can only be used with templated
> > functions.
> >
> > - Jonathan M Davis
>
> The trouble
On Wednesday, 27 June 2012 at 03:54:12 UTC, Jonathan M Davis
wrote:
That isn't legal. auto ref can only be used with templated
functions.
- Jonathan M Davis
The trouble is, distinguishing between when it should be illegal
seems like a blur to me.
Consider all the cases
On Wednesday, June 27, 2012 02:54:49 Mehrdad wrote:
> On Tuesday, 26 June 2012 at 16:37:30 UTC, Timon Gehr wrote:
> > On 06/26/2012 06:17 PM, Mehrdad wrote:
> >> void test1(T)(auto ref T) { }
> >> void test2() { int a = 5; test1!(int)(a); }
> >>
>
On Tuesday, 26 June 2012 at 16:37:30 UTC, Timon Gehr wrote:
On 06/26/2012 06:17 PM, Mehrdad wrote:
void test1(T)(auto ref T) { }
void test2() { int a = 5; test1!(int)(a); }
Is there any reason this should fail?
There is not. I suppose the compiler completes instantiation
without
looking at
On 06/26/2012 06:17 PM, Mehrdad wrote:
void test1(T)(auto ref T) { }
void test2() { int a = 5; test1!(int)(a); }
Is there any reason this should fail?
There is not. I suppose the compiler completes instantiation without
looking at the function parameter.
void test1(T)(auto ref T) { }
void test2() { int a = 5; test1!(int)(a); }
Is there any reason this should fail?
On Friday, 15 June 2012 at 07:15:50 UTC, Jonathan M Davis wrote:
On Friday, June 15, 2012 09:09:48 Don Clugston wrote:
On 10/06/12 23:43, Jonathan M Davis wrote:
> On Sunday, June 10, 2012 23:23:57 Mehrdad wrote:
>> I honestly don't see the POINT of having a "dynamic array
>> literal".
>>
>> Wh
On Friday, June 15, 2012 09:09:48 Don Clugston wrote:
> On 10/06/12 23:43, Jonathan M Davis wrote:
> > On Sunday, June 10, 2012 23:23:57 Mehrdad wrote:
> >> I honestly don't see the POINT of having a "dynamic array
> >> literal".
> >>
> >> What's the point of making the literals dynamic?
> >>
> >
On 10/06/12 23:43, Jonathan M Davis wrote:
On Sunday, June 10, 2012 23:23:57 Mehrdad wrote:
I honestly don't see the POINT of having a "dynamic array
literal".
What's the point of making the literals dynamic?
They should all be static, and only converted to dynamic if
necessary from the contex
"Steven Schveighoffer" , dans le message (digitalmars.D:169718), a
écrit :
> Note that D1 was like this, [1,2,3] was auto-typed to int[3u]. It was a
> constant source of pain that I would not like to revisit. Especially
> since static arrays are now passed by value.
Artur Skawina , dans le message (digitalmars.D:169717), a écrit :
> On 06/11/12 12:06, Christophe Travert wrote:
>> Jonathan M Davis , dans le message (digitalmars.D:169705), a écrit :
>>> auto found = find([1, 2, 3, 4, 5], 3);
>>
>> No problem if the rule could
27;t understand... could someone give me an example of what would
break if we used the rule I suggested?
Anything that uses type deduction? Most of the time, you do *not* want a
static array, especially for template functions that use IFTI.
Note that D1 was like this, [1,2,3] was auto-typed
On 06/11/12 12:06, Christophe Travert wrote:
> Jonathan M Davis , dans le message (digitalmars.D:169705), a écrit :
>> auto found = find([1, 2, 3, 4, 5], 3);
>
> No problem if the rule could be the following:
> - array literals are static by default
> - array literals a
Jonathan M Davis , dans le message (digitalmars.D:169705), a écrit :
> auto found = find([1, 2, 3, 4, 5], 3);
No problem if the rule could be the following:
- array literals are static by default
- array literals are copied to the heap when assigned to a dynamic
array.
- the former r
On Monday, June 11, 2012 05:09:49 Mehrdad wrote:
> On Monday, 11 June 2012 at 03:05:36 UTC, Jonathan M Davis wrote:
> > What are you trying to fix beyond assignments to static arrays
> > with array literals?
>
> Just the fact that it would reduce unnecessary heap allocations.
> I'm not trying to '
On Monday, 11 June 2012 at 03:05:36 UTC, Jonathan M Davis wrote:
What are you trying to fix beyond assignments to static arrays
with array literals?
Just the fact that it would reduce unnecessary heap allocations.
I'm not trying to 'fix' it though, as it's not broken. (Then
again, neither is i
>
> Yes, that's precisely why your statement didn't make sense to me.
>
> :)
> :
> > But for any templated function which returns a portion of its
> > argument, having it take a static array for that argument would
> > be horribly broken. For instance,
&
:)
But for any templated function which returns a portion of its
argument, having it take a static array for that argument would
be horribly broken. For instance,
auto found = find([1, 2, 3, 4, 5], 3);
_would_ definitely return a slice which referred to garbage
were array literals
static an
On Monday, June 11, 2012 04:13:42 Mehrdad wrote:
> On Monday, 11 June 2012 at 00:57:45 UTC, Jonathan M Davis wrote:
> > And if all range-based functions were altered to work with
> > static arrays, and we made array literals static, then this
> > example would _still_ be
On Monday, 11 June 2012 at 00:57:45 UTC, Jonathan M Davis wrote:
And if all range-based functions were altered to work with
static arrays, and we made array literals static, then this
example would _still_ be broken
auto found = find(arr, [1, 2]);
Sorry, I don't quite seem to f
On Monday, June 11, 2012 02:45:00 Mehrdad wrote:
> On Monday, 11 June 2012 at 00:16:48 UTC, Jonathan M Davis wrote:
> > auto found = find(arr, [1, 2]);
> >
> > wouldn't compile, because [1, 2] would be considered a static
> > array, which
> > isn't a
On Monday, 11 June 2012 at 00:16:48 UTC, Jonathan M Davis wrote:
auto found = find(arr, [1, 2]);
wouldn't compile, because [1, 2] would be considered a static
array, which
isn't a range.
- Jonathan M Davis
Uh... that's pretty much just saying, "code that explicitly
de
> > - Jonathan M Davis
>
> "Type deduction"? o.O
> I don't understand... could someone give me an example of what
> would break if we used the rule I suggested?
Pretty much anything involving templates would break. For instance,
auto found = find(arr, [1, 2]);
wou
Type deduction.
Exactly. And if they need to be assigned to a static array,
then the compiler
can automatically do what it needs to do to avoid the extra
heap allocation.
- Jonathan M Davis
"Type deduction"? o.O
I don't understand... could someone give me an example of what
would break
On Monday, June 11, 2012 01:35:41 Timon Gehr wrote:
> On 06/11/2012 12:28 AM, Mehrdad wrote:
> > Ugh... you keep on saying "on occasion" and "particular case", making it
> > seem like it's such a rarity that it's not worth mentioning.
> >
> >
> >
> > Regarding your examples: the rule is quite si
On 06/11/2012 12:28 AM, Mehrdad wrote:
Ugh... you keep on saying "on occasion" and "particular case", making it
seem like it's such a rarity that it's not worth mentioning.
Regarding your examples: the rule is quite simple:
- Literals are static by default
- If they are to be assigned to a dy
Ugh... you keep on saying "on occasion" and "particular case",
making it seem like it's such a rarity that it's not worth
mentioning.
Regarding your examples: the rule is quite simple:
- Literals are static by default
- If they are to be assigned to a dynamic array, then make them
dynamic i
the context.
>
> But I really don't see the benefit of allocating them on the heap
> just because we can... perhaps someone can enlighten me?
In the vast majority of cases where an array literal is used, it's assigned to
a dynamic array. And if you do something like
auto
I honestly don't see the POINT of having a "dynamic array
literal".
What's the point of making the literals dynamic?
They should all be static, and only converted to dynamic if
necessary from the context.
But I really don't see the benefit of allocating them on the heap
just because we can.
ou're forced to create one on the stack first.
>>>>>>>
>>>>>>> int[5] array = [1, 2, 3, 4, 5];
>>>>>>> func(array);
>>>>>>>
>>>>>>
>>>>>> func(cast(int[5])[1,2,3,4,5]);
>
Using 'static' is "inventing yet another literal syntax" as well.
In a way - yes. But i think "static[...]" would be much better than "[...]S".
Obviously, none is much better than the other.
...
The isStaticArray!A problem is partially related to how
t we're trying to solve, then that's a matter of fixing the
>>>>> optimizer, not the language.
>>>>>
>>>>
>>>> This is not about optimization. Allocating is simply incorrect. It is a
>>>> 'wrong code' bug.
>&g
cally in these cases,
The compiler should do the right thing, not automatically apply a hack
that only works for CTFEable right hand sides.
right now it
doesn't. This hack won't of course work for the program mentioned in this
thread.
The isStaticArray!A problem is partially related to how
writefln(typeof([1, 2, 3, 4, 5]).stringof) is int[5u] in D1 haha.
d you've also shown that we don't need a new syntax
> to accomplish this.
When you want to avoid the heap allocation, you can always use hacks such as:
template static_array(alias da) {
typeof(da[0])[da.length] static_array = da;
}
f(...) {
int[3] a = static_array!([1
Am 10.06.2012 01:02, schrieb Timon Gehr:
> On 06/10/2012 12:34 AM, Jonathan M Davis wrote:
>> On Sunday, June 10, 2012 00:15:01 Timon Gehr wrote:
>>> D static array literals don't perform a costly heap allocation. It is
>>> simply a bug in the implementation. This is not a compelling reason to
>>>
On Sunday, June 10, 2012 01:02:40 Timon Gehr wrote:
> On 06/10/2012 12:34 AM, Jonathan M Davis wrote:
> > On Sunday, June 10, 2012 00:15:01 Timon Gehr wrote:
> >> D static array literals don't perform a costly heap allocation. It is
> >> simply a bug in the implementation. This is not a compelling
On 10-06-2012 01:02, Timon Gehr wrote:
On 06/10/2012 12:34 AM, Jonathan M Davis wrote:
On Sunday, June 10, 2012 00:15:01 Timon Gehr wrote:
D static array literals don't perform a costly heap allocation. It is
simply a bug in the implementation. This is not a compelling reason to
add new syntax.
On 06/10/2012 12:34 AM, Jonathan M Davis wrote:
On Sunday, June 10, 2012 00:15:01 Timon Gehr wrote:
D static array literals don't perform a costly heap allocation. It is
simply a bug in the implementation. This is not a compelling reason to
add new syntax.
D
DMD
doesn't _have_ static array
On Sunday, June 10, 2012 00:15:01 Timon Gehr wrote:
> D static array literals don't perform a costly heap allocation. It is
> simply a bug in the implementation. This is not a compelling reason to
> add new syntax.
D doesn't _have_ static array literals. It only has dynamic array literals.
int[5]
On 06/10/2012 12:05 AM, timotheecour wrote:
(apologies for cross-posting here, I feel this is a better place to ask
than in my original post where I only received 1 answer that seemed in
favor of this:
http://d.puremagic.com/issues/show_bug.cgi?id=8008 which was 2 months ago).
Please see to the
; a[1]=i+1;
a[2]=i+2;a[3]=i+3;a[4]=i+4;a[5]=i+5;a[6]=i+6;a[7]=i+7;a[8]=i+8;a[9]=i+9;
Having the new syntax auto
a=[i,i+1,i+2,i+3,i+4,i+5,i+6,i+7,i+8,i+9]S would prevent the
intermediate heap allocation and should be at least as fast as
the C version, possibly faster if SSE instructions are
GCC is good, it knows many tricks, it contains a lot of pattern matching
code and other code to allow such vectorizations, and that C code is
almost transparent & standard (restrict is standard, and I think
__builtin_assume_aligned isn't too much hard to #define away when not
available. And
On Tue, May 22, 2012 at 1:52 PM, bearophile wrote:
> On Reddit they have linked an article that shows auto vectorization in GCC
> 4.7:
>
> http://locklessinc.com/**articles/vectorize/<http://locklessinc.com/articles/vectorize/>
>
> http://www.reddit.com/r/**pr
22.05.2012 22:52, bearophile написал:
How is the development of the D SIMD ops going? Are those efforts (maybe
with the help of another higher level Phobos lib) going to avoid the
silly problems shown in that article?
So the question is: do we need `aligned(T)(T)` function? It can work
like cu
On Reddit they have linked an article that shows auto
vectorization in GCC 4.7:
http://locklessinc.com/articles/vectorize/
http://www.reddit.com/r/programming/comments/tz6ml/autovectorization_with_gcc_47/
GCC is good, it knows many tricks, it contains a lot of pattern
matching code and other
On Thursday, May 17, 2012 13:49:16 Roman D. Boiko wrote:
> Is there anything preventing us from adding constraints on the
> auto function return value? I mean, such language extension seems
> to be quite useful.
>
> For example, it would be no longer necessary to provide meth
On Thursday, 17 May 2012 at 21:09:10 UTC, Jonathan M Davis wrote:
It would still be necessary, because the compiler needs to know
what the
actual return type is. Knowing that the type implements
popFront, front, and
empty isn't enough. It needs to know the actual, physical
layout of the type
to
0
X-Mailer: GMX.com Web Mailer
x-registered: 0
X-GMX-UID: pi3HbzE+3zOlOEKpenAhypZ+IGRvb0CJ
On Thursday, May 17, 2012 13:49:16 Roman D. Boiko wrote:
> Is there anything preventing us from adding constraints on the
> auto function return value? I mean, such language extension seems
> to be qui
On Thursday, 17 May 2012 at 11:49:18 UTC, Roman D. Boiko wrote:
Is there anything preventing us from adding constraints on the
auto function return value? I mean, such language extension
seems to be quite useful.
For example, it would be no longer necessary to provide method
bodies for
Is there anything preventing us from adding constraints on the
auto function return value? I mean, such language extension seems
to be quite useful.
For example, it would be no longer necessary to provide method
bodies for functions with auto return values.
In many cases this would
On 2011-12-20 18:39:02 +, Timon Gehr said:
On 12/20/2011 07:16 PM, dsimcha wrote:
On Tuesday, 20 December 2011 at 17:46:40 UTC, Jonathan M Davis wrote:
Assuming that the assignment can still take place, then making auto
infer non-
const and non-immutable would be an improvement IMHO
On Tue, 20 Dec 2011 19:16:26 +0100, dsimcha wrote:
On Tuesday, 20 December 2011 at 17:46:40 UTC, Jonathan M Davis wrote:
Assuming that the assignment can still take place, then making auto
infer non-
const and non-immutable would be an improvement IMHO. However, there
_are_ cases where
On 12/20/2011 07:16 PM, dsimcha wrote:
On Tuesday, 20 December 2011 at 17:46:40 UTC, Jonathan M Davis wrote:
Assuming that the assignment can still take place, then making auto
infer non-
const and non-immutable would be an improvement IMHO. However, there
_are_ cases where you'd have to r
On Tuesday, 20 December 2011 at 17:46:40 UTC, Jonathan M Davis
wrote:
Assuming that the assignment can still take place, then making
auto infer non-
const and non-immutable would be an improvement IMHO. However,
there _are_ cases where you'd have to retain const - a prime
example being cl
On Tuesday, December 20, 2011 09:23:31 dsimcha wrote:
> The changes made to IFTI in DMD 2.057 are great, but they reveal another
> hassle with getting generic code to play nice with const.
>
> import std.range, std.array;
>
> ElementType!R sum(R)(R range) {
> if(range.empty)
On Tue, 20 Dec 2011 15:23:31 +0100, dsimcha wrote:
The changes made to IFTI in DMD 2.057 are great, but they reveal another
hassle with getting generic code to play nice with const.
import std.range, std.array;
ElementType!R sum(R)(R range) {
if(range.empty) return 0;
auto ans
The changes made to IFTI in DMD 2.057 are great, but they reveal another
hassle with getting generic code to play nice with const.
import std.range, std.array;
ElementType!R sum(R)(R range) {
if(range.empty) return 0;
auto ans = range.front;
range.popFront();
foreach(elem
On 12/19/2011 4:05 AM, Martin Nowak wrote:
> On Sat, 17 Dec 2011 20:54:24 +0100, Brad Roberts wrote:
>
>> On 12/17/2011 4:56 AM, Robert Clipsham wrote:
>>> On 17/12/2011 06:40, Brad Roberts wrote:
On 12/16/2011 1:29 PM, Brad Anderson wrote:
> On Thu, Dec 15, 2011 at 6:43 PM, Brad
>
On Sat, 17 Dec 2011 20:54:24 +0100, Brad Roberts
wrote:
On 12/17/2011 4:56 AM, Robert Clipsham wrote:
On 17/12/2011 06:40, Brad Roberts wrote:
On 12/16/2011 1:29 PM, Brad Anderson wrote:
On Thu, Dec 15, 2011 at 6:43 PM, Brad
Robertsmailto:bra...@puremagic.com>> wrote:
Left to do:
On 12/17/2011 4:56 AM, Robert Clipsham wrote:
> On 17/12/2011 06:40, Brad Roberts wrote:
>> On 12/16/2011 1:29 PM, Brad Anderson wrote:
>>> On Thu, Dec 15, 2011 at 6:43 PM, Brad
>>> Robertsmailto:bra...@puremagic.com>> wrote:
>>>
>>>
>>> Left to do:
>>>
>>> 1) deploy changes to the tes
601 - 700 of 1018 matches
Mail list logo
