On Wed, 16 Nov 2011 18:25:48 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 11/16/2011 11:39 PM, Timon Gehr wrote:
I think this is a better solution:
void foo2(T: ParameterTypeTuple!foo[0])(T t){foo(t);}
Then it is just a matter of applying proper value range propagation for
IFTY:
void
On Wed, 16 Nov 2011 17:39:16 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 11/16/2011 10:56 PM, Steven Schveighoffer wrote:
On Wed, 16 Nov 2011 16:16:48 -0500, Timon Gehr timon.g...@gmx.ch
wrote:
On 11/16/2011 09:00 PM, Steven Schveighoffer wrote:
On Wed, 16 Nov 2011 14:26:57 -0500, Timon
On 11/17/2011 03:19 PM, Steven Schveighoffer wrote:
On Wed, 16 Nov 2011 17:39:16 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 11/16/2011 10:56 PM, Steven Schveighoffer wrote:
On Wed, 16 Nov 2011 16:16:48 -0500, Timon Gehr timon.g...@gmx.ch
wrote:
On 11/16/2011 09:00 PM, Steven
On Thu, 17 Nov 2011 12:31:58 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 11/17/2011 03:19 PM, Steven Schveighoffer wrote:
What does writelnInferConst!T do? I'm afraid I'm not getting what you
are saying.
I was thinking writeln should do this:
void writeln(T...)(const T args) {...}
As
On 11/17/2011 07:23 PM, Steven Schveighoffer wrote:
On Thu, 17 Nov 2011 12:31:58 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 11/17/2011 03:19 PM, Steven Schveighoffer wrote:
What does writelnInferConst!T do? I'm afraid I'm not getting what you
are saying.
I was thinking writeln should
On Tue, 15 Nov 2011 13:45:02 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 11/15/2011 04:53 PM, Steven Schveighoffer wrote:
Yes, but this is spelled out because copying a static array requires
moving data. However, this does *not* require a hidden allocation (even
though it does do a hidden
On 11/16/2011 02:22 PM, Steven Schveighoffer wrote:
On Tue, 15 Nov 2011 13:45:02 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 11/15/2011 04:53 PM, Steven Schveighoffer wrote:
Yes, but this is spelled out because copying a static array requires
moving data. However, this does *not* require
On 11/16/2011 08:26 PM, Timon Gehr wrote:
auto a = [new Foo, new Bar, new Qux]; // I want that to work.
(It currently does, if that was unclear)
On Wed, 16 Nov 2011 14:26:57 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 11/16/2011 02:22 PM, Steven Schveighoffer wrote:
On Tue, 15 Nov 2011 13:45:02 -0500, Timon Gehr timon.g...@gmx.ch
wrote:
Note that this is an explicit allocation:
int[] a = [1,2,3]; // just as explicit as a
On Wed, 16 Nov 2011 15:00:16 -0500, Steven Schveighoffer
schvei...@yahoo.com wrote:
The one case which is difficult to do is initializing a fixed-size array
with a literal that uses runtime data. I suppose we'd need a function
that returns a fixed-sized array made of its arguments, and
On 11/16/2011 09:00 PM, Steven Schveighoffer wrote:
On Wed, 16 Nov 2011 14:26:57 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 11/16/2011 02:22 PM, Steven Schveighoffer wrote:
On Tue, 15 Nov 2011 13:45:02 -0500, Timon Gehr timon.g...@gmx.ch
wrote:
Note that this is an explicit allocation:
On Wed, 16 Nov 2011 21:00:16 +0100, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Wed, 16 Nov 2011 14:26:57 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 11/16/2011 02:22 PM, Steven Schveighoffer wrote:
On Tue, 15 Nov 2011 13:45:02 -0500, Timon Gehr timon.g...@gmx.ch
wrote:
Note
On Wed, 16 Nov 2011 16:47:58 -0500, Simen Kjærås simen.kja...@gmail.com
wrote:
On Wed, 16 Nov 2011 21:00:16 +0100, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Wed, 16 Nov 2011 14:26:57 -0500, Timon Gehr timon.g...@gmx.ch
wrote:
On 11/16/2011 02:22 PM, Steven Schveighoffer
On Wed, 16 Nov 2011 16:16:48 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 11/16/2011 09:00 PM, Steven Schveighoffer wrote:
On Wed, 16 Nov 2011 14:26:57 -0500, Timon Gehr timon.g...@gmx.ch
wrote:
On 11/16/2011 02:22 PM, Steven Schveighoffer wrote:
On Tue, 15 Nov 2011 13:45:02 -0500, Timon
On 11/16/2011 10:56 PM, Steven Schveighoffer wrote:
On Wed, 16 Nov 2011 16:16:48 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 11/16/2011 09:00 PM, Steven Schveighoffer wrote:
On Wed, 16 Nov 2011 14:26:57 -0500, Timon Gehr timon.g...@gmx.ch
wrote:
On 11/16/2011 02:22 PM, Steven
On 11/16/2011 11:39 PM, Timon Gehr wrote:
I think this is a better solution:
void foo2(T: ParameterTypeTuple!foo[0])(T t){foo(t);}
Then it is just a matter of applying proper value range propagation for
IFTY:
void bar(T: short)(T t){...}
void main(){
bar(1); // ok
}
BTW, this already
On Mon, 14 Nov 2011 16:28:52 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 11/14/2011 09:39 PM, Steven Schveighoffer wrote:
Look at the code generated for enum a = [1, 2, 3]. using a is replaced
with a call to _d_arrayliteral. There is no CTFE going on.
There is some ctfe going on, but the
On 11/15/2011 04:53 PM, Steven Schveighoffer wrote:
On Mon, 14 Nov 2011 16:28:52 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 11/14/2011 09:39 PM, Steven Schveighoffer wrote:
Look at the code generated for enum a = [1, 2, 3]. using a is replaced
with a call to _d_arrayliteral. There is no
On 11/14/2011 01:02 AM, bearophile wrote:
Jonathan M Davis:
import std.algorithm;
void main() {
enum a = [3, 1, 2];
enum s = sort(a);
assert(equal(a, [3, 1, 2]));
assert(equal(s, [1, 2, 3]));
}
It's not a bug. Those an manifest constants. They're copy-pasted into whatever
On 11/14/2011 09:27 AM, Timon Gehr wrote:
On 11/14/2011 01:02 AM, bearophile wrote:
Jonathan M Davis:
import std.algorithm;
void main() {
enum a = [3, 1, 2];
enum s = sort(a);
assert(equal(a, [3, 1, 2]));
assert(equal(s, [1, 2, 3]));
}
It's not a bug. Those an manifest constants. They're
On Mon, 14 Nov 2011 10:27:21 +0200, Timon Gehr timon.g...@gmx.ch wrote:
It is the right design. Why should enum imply const or immutable? (or
inout, for that matter). They are completely orthogonal.
enum Enum{
opt1,
opt2,
}
void main(){
auto moo = Enum.opt1;
moo =
On 11/14/2011 10:20 AM, so wrote:
On Mon, 14 Nov 2011 10:27:21 +0200, Timon Gehr timon.g...@gmx.ch wrote:
It is the right design. Why should enum imply const or immutable? (or
inout, for that matter). They are completely orthogonal.
enum Enum{
opt1,
opt2,
}
void main(){
auto moo = Enum.opt1;
so wrote:
immutable a;
sort(a);
But with current design you can do:
enum a;
sort(a);
Which is to me, quite wrong.
It is not wrong at all.
On Mon, 14 Nov 2011 03:27:21 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 11/14/2011 01:02 AM, bearophile wrote:
Jonathan M Davis:
import std.algorithm;
void main() {
enum a = [3, 1, 2];
enum s = sort(a);
assert(equal(a, [3, 1, 2]));
assert(equal(s, [1, 2, 3]));
}
It's
On 11/14/2011 02:13 PM, Steven Schveighoffer wrote:
On Mon, 14 Nov 2011 03:27:21 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 11/14/2011 01:02 AM, bearophile wrote:
Jonathan M Davis:
import std.algorithm;
void main() {
enum a = [3, 1, 2];
enum s = sort(a);
assert(equal(a, [3, 1, 2]));
On Mon, 14 Nov 2011 13:37:18 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 11/14/2011 02:13 PM, Steven Schveighoffer wrote:
On Mon, 14 Nov 2011 03:27:21 -0500, Timon Gehr timon.g...@gmx.ch
wrote:
On 11/14/2011 01:02 AM, bearophile wrote:
Jonathan M Davis:
import std.algorithm;
void
On 11/14/2011 08:37 PM, Steven Schveighoffer wrote:
On Mon, 14 Nov 2011 13:37:18 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 11/14/2011 02:13 PM, Steven Schveighoffer wrote:
On Mon, 14 Nov 2011 03:27:21 -0500, Timon Gehr timon.g...@gmx.ch
wrote:
On 11/14/2011 01:02 AM, bearophile wrote:
On Mon, 14 Nov 2011 14:59:50 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 11/14/2011 08:37 PM, Steven Schveighoffer wrote:
On Mon, 14 Nov 2011 13:37:18 -0500, Timon Gehr timon.g...@gmx.ch
wrote:
On 11/14/2011 02:13 PM, Steven Schveighoffer wrote:
On Mon, 14 Nov 2011 03:27:21 -0500, Timon
On 11/14/2011 09:39 PM, Steven Schveighoffer wrote:
On Mon, 14 Nov 2011 14:59:50 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 11/14/2011 08:37 PM, Steven Schveighoffer wrote:
On Mon, 14 Nov 2011 13:37:18 -0500, Timon Gehr timon.g...@gmx.ch
wrote:
On 11/14/2011 02:13 PM, Steven
On Mon, 14 Nov 2011 15:13:20 +0200, Steven Schveighoffer
schvei...@yahoo.com wrote:
There is definitely some debatable practice here for wherever enum is
used on an array.
Consider that:
enum a = hello;
foo(a);
Does not allocate heap memory, even though hello is a reference type.
Do you remember if this bug is in Bugzilla?
import std.algorithm;
void main() {
enum a = [3, 1, 2];
enum s = sort(a);
assert(equal(a, [3, 1, 2]));
assert(equal(s, [1, 2, 3]));
}
Bye,
bearophile
On Sunday, November 13, 2011 17:54:14 bearophile wrote:
Do you remember if this bug is in Bugzilla?
import std.algorithm;
void main() {
enum a = [3, 1, 2];
enum s = sort(a);
assert(equal(a, [3, 1, 2]));
assert(equal(s, [1, 2, 3]));
}
It's not a bug. Those an manifest
Jonathan M Davis:
import std.algorithm;
void main() {
enum a = [3, 1, 2];
enum s = sort(a);
assert(equal(a, [3, 1, 2]));
assert(equal(s, [1, 2, 3]));
}
It's not a bug. Those an manifest constants. They're copy-pasted into
whatever
code you used them in. So,
On Sunday, November 13, 2011 19:02:01 bearophile wrote:
Jonathan M Davis:
import std.algorithm;
void main() {
enum a = [3, 1, 2];
enum s = sort(a);
assert(equal(a, [3, 1, 2]));
assert(equal(s, [1, 2, 3]));
}
It's not a bug. Those an manifest
On Mon, 14 Nov 2011 02:09:40 +0200, Jonathan M Davis jmdavisp...@gmx.com
wrote:
It depends entirely on what you're trying to do. If you understand how
manifest constants work, then they can be quite advantageous. What you
probably really want for arrays though is not an enum but just a const
On Mon, 14 Nov 2011 02:50:50 +0200, Jonathan M Davis jmdavisp...@gmx.com
wrote:
No. Those are two _very_ different things.
immutable a = [3, 1, 2];
creates a variable of type immutable(int[]). You takes up memory. You
can take
its address - e.g. a. It exists even if you don't use it at
On Monday, November 14, 2011 04:03:54 so wrote:
Trying to remember the discussions on digitalmars.D regarding
enum/immutable. There were contradicting opinions.
You ask the same question at two different times, you get at least two
different answers, especially on this matter.
There was/is
37 matches
Mail list logo
