Walter Bright Wrote:
> Tomek Sowiñski wrote:
> > Oh, and if the problem called for a turbo spreadsheet, I had to re-learn
> > the function names all over because in VBA they're English. :-/
>
Yes, localized Excel is a real pain.
> My father spent years in Japan after the war, and of course Japa
"Andrej Mitrovic" wrote in message
news:mailman.28.1283307608.858.digitalmar...@puremagic.com...
>
>That is all that I thought enums are useful for. But apparently an
>enum is a type and you can instantiate it and I don't even know
>what an enum is anymore. I'll just stay out of this discussi
"Daniel Gibson" wrote in message
news:i5kbpr$24t...@digitalmars.com...
> bearophile schrieb:
>> Daniel Gibson:
>>
>>> Why not use the non-fictional const keyword? "The const attribute
>>> declares constants that can be evaluated at compile time."[1]
>>
>> But you can use const for constants that
This whole enum thing is making my head explode out of confusion. I
thought having a tag was just supossed to be used as a namespace for
enumerated values. E.g.:
enum { red = 1, green, blue }
...
if (getValue() == green) {
do..
}
and:
enum Tagged { red = 1, green, blue }
...
if (getValue() =
Daniel Gibson:
> Really? Than that definition from the language docs is inaccurate.
This compiles, here n is known at run-time only:
void main(string[] args) {
const int n = args.length;
}
This compiles, but I think it's a bug:
void main(string[] args) {
enum int n = args.length;
}
T
bearophile schrieb:
Daniel Gibson:
Why not use the non-fictional const keyword? "The const attribute
declares constants that can be evaluated at compile time."[1]
But you can use const for constants that are known at run-time only. While you
can't use enum for constant known at run-time.
Daniel Gibson:
> Why not use the non-fictional const keyword? "The const attribute
> declares constants that can be evaluated at compile time."[1]
But you can use const for constants that are known at run-time only. While you
can't use enum for constant known at run-time.
> "enum int n = 10;"
bearophile wrote:
ctconst is a fictional keyword that denotes compile-time constants. Now you are
probably able to see that there is no correlation between the n and Color.
Why not use the non-fictional const keyword? "The const attribute
declares constants that can be evaluated at compile
"Daniel Gibson" wrote in message
news:mailman.26.1283301521.858.digitalmar...@puremagic.com...
>
> Then there still is the consistency-issue (anon. enums are treated
> differently then named enums).
>
Anon. enums *are* fundamentally different from named enums. It's already
inconsistent.
Daniel Gibson:
> Then there still is the consistency-issue (anon. enums are treated
> differently then named enums).
Look at this:Se
enum int n = 10;
enum Color { Red, Green, Blue }
Color color;
if (color == Color.Red) { ...
Color is a sequence of symbols, Red, Green and Blue, named Color. When
bearophile schrieb:
Daniel Gibson:
I sometimes find it convenient to just treat those values as integers,
Yes, I am sure in some situations it can be handy. But it's a a bit of
convenience that has a too much high price, the semantics is less clean, and
it's more bug prone. So no thanks. Kee
Daniel Gibson:
> I sometimes find it convenient to just treat those values as integers,
Yes, I am sure in some situations it can be handy. But it's a a bit of
convenience that has a too much high price, the semantics is less clean, and
it's more bug prone. So no thanks. Keeping things tidy is mo
(Discussion originally on digitalmars-d-learn. Moving to digitalmars-d
list.)
Eduardo Cavazos wrote:
> Here's a short program which creates a type for points and overloads
'+'
> to do element wise addition as well as addition to floats, however it
> produces an error:
>
> ---
"Daniel Gibson" wrote in message
news:mailman.24.1283298345.858.digitalmar...@puremagic.com...
> ---
> int x;
> stream.read(x); // btw: this often sucks - why not x = stream.readInt()?
Better yet: stream.read!int()
> if(x == MyEnum.DIE)
> return 0;
> else if(x == MyEnum.CALLFOO)
> foo(x);
> ---
Andrei Alexandrescu wrote:
Relevant reading:
http://www.paulgraham.com/taste.html
Art is indeed a relational value (has value only defined jointly by a
creator and a recipient) but that doesn't make it wholly relative.
Where I draw the line is when someone tries to impose their taste upon ot
bearophile schrieb:
A way to tell them apart is the presence of the EnumTag, if it's present, then
the enum is a new type:
enum V1 = 10;
enum { V2 = 20 }
enum Foo { V3 }
void main() {
assert(V1 == 10);// OK
assert(V2 == 20);// OK
assert(Foo.V3 == 0); // ERROR, type mismatch
A way to tell them apart is the presence of the EnumTag, if it's present, then
the enum is a new type:
enum V1 = 10;
enum { V2 = 20 }
enum Foo { V3 }
void main() {
assert(V1 == 10);// OK
assert(V2 == 20);// OK
assert(Foo.V3 == 0); // ERROR, type mismatch
}
Bye,
bearophile
Probably each of the ~25 bugs of the short list I have shown here recently need
a bit of discussion (also because some of them are little breaking changes over
current DMD and/or TDPL). Even if some of them may need to wait in Bugzilla for
two years, it's positive to discuss them already. But yo
"dsimcha" wrote in message
news:i5jtdn$1g4...@digitalmars.com...
>
> Isn't this a core language feature that's in the spec but is only
> currently
> implemented for arrays? I thought eventually uniform function call syntax
> was
> coming for classes and structs, too.
I've been really wishing
Lutger:
> wtf it works! That's a cool trick / workaround, thanks.
See bug 4085
Bye,
bearophile
On Tuesday, August 31, 2010 14:49:43 dsimcha wrote:
> Isn't this a core language feature that's in the spec but is only currently
> implemented for arrays? I thought eventually uniform function call syntax
> was coming for classes and structs, too.
There are people who keep asking for it, but as
On Wed, Sep 1, 2010 at 00:05, Lutger wrote:
> wtf it works! That's a cool trick / workaround, thanks.
>
>
That'd be cool if this worked too:
foreach(i,_; test) // since test is iterable
or even:
foreach(i,_; typeof(test)) // int[3] -> consider it as (int,int,int) and
iterate.
Halas, no. Thou
On Tue, Aug 31, 2010 at 23:49, dsimcha wrote:
>
>
> Isn't this a core language feature that's in the spec but is only currently
> implemented for arrays? I thought eventually uniform function call syntax
> was
> coming for classes and structs, too.
>
Yes I heard that too. But it will be at leas
Philippe Sigaud wrote:
...
>> I want this to work or something like it, is it possible?
>>
>> enum test = [1,2, 3];
>>
>> foreach(i; 0..test.length) {
>>pragma(msg, to!string(test[i]) );
>> }
>>
>
> Well, 0..someEnum is not recognized by the compiler. The workaround is to
> create a typetuple
== Quote from Philippe Sigaud (philippe.sig...@gmail.com)'s article
> std.typecons is full of good stuff. I learnt quite a lot reading it. The Any
> code gave many hours of reading, compiling the resulting code in my head, so
> to say. Then I went a little mad ;)
> My initial suggestion for your OP
On Tue, Aug 31, 2010 at 22:41, Lutger wrote:
>
> Wait what, we have static foreach? I thought that didn't work out.
>
>
foreach is automatically done at compile-time if you iterate in typetuples
string toStrings(Args...)(Args args) //btw, I regularly need this
{
string result;
foreach(i,Type
On Tue, Aug 31, 2010 at 20:03, dsimcha wrote:
> == Quote from Lutger (lutger.blijdest...@gmail.com)'s article
> > Instead of std.mixins, perhaps it is better to fold the code with
> std.typecons
> > or create new modules as needed (std.pattern?).
>
> I initially thought std.mixins would be a good
Am 30.08.2010 19:34, schrieb Andrei Alexandrescu:
On 8/30/10 12:28 PDT, Adam B wrote:
Thanks. I'll use the puremagic issue tracker. And by the way, if
http://www.d-programming-language.org holds a proposed style change
I'll vote for it! It feels much more modern and polished. That said,
having t
Nick Sabalausky wrote:
> "Lutger" wrote in message
> news:i5jmlc$13l...@digitalmars.com...
>> Nick Sabalausky wrote:
>>
>>> "Lutger" wrote in message
>>> news:i5jiap$rv...@digitalmars.com...
dsimcha wrote:
>It can still be useful if you also change the loop body a
> little, for exam
dsimcha:
> I thought about this. Simple loop unrolling doesn't seem like a very useful
> optimization on modern hardware because branch prediction and pipelining have
> gotten so good. It can still be useful if you also change the loop body a
> little,
> for example using multiple accumulators t
"Lutger" wrote in message
news:i5jmlc$13l...@digitalmars.com...
> Nick Sabalausky wrote:
>
>> "Lutger" wrote in message
>> news:i5jiap$rv...@digitalmars.com...
>>> dsimcha wrote:
It can still be useful if you also change the loop body a
little, for example using multiple accumulators to
== Quote from Lutger (lutger.blijdest...@gmail.com)'s article
> Nick Sabalausky wrote:
> > "Lutger" wrote in message
> > news:i5jiap$rv...@digitalmars.com...
> >> dsimcha wrote:
> >>
> >> ...
> My suggestion is to include a mixin for unrolling loops.
> >>>
> >>> I thought about this. Simple
Nick Sabalausky wrote:
> "Lutger" wrote in message
> news:i5jiap$rv...@digitalmars.com...
>> dsimcha wrote:
>>
>> ...
My suggestion is to include a mixin for unrolling loops.
>>>
>>> I thought about this. Simple loop unrolling doesn't seem like a very
>>> useful
>>> optimization on modern h
On 2010-08-31 18:11, Denis Koroskin wrote:
On Tue, 31 Aug 2010 19:13:17 +0400, Jacob Carlborg wrote:
On 2010-08-31 05:17, Andrei Alexandrescu wrote:
On 8/30/10 20:04 PDT, dsimcha wrote:
I've been toying for a long time with the idea of a std.mixins for
Phobos that
would contain meta-implemen
"Lutger" wrote in message
news:i5jiap$rv...@digitalmars.com...
> dsimcha wrote:
>
> ...
>>> My suggestion is to include a mixin for unrolling loops.
>>
>> I thought about this. Simple loop unrolling doesn't seem like a very
>> useful
>> optimization on modern hardware because branch prediction
Hello Torarin,
2010/8/31 BCS :
Hello Torarin,
So reviews are useless?
Without context, yes they are useless. With context, your just
looking at correlation: i.e "we like/dislike the same things".
I can understand the premise of the view that art cannot be
quality-assessed, but I think th
Hello dsimcha,
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
On 8/30/10 20:04 PDT, dsimcha wrote:
I've been toying for a long time with the idea of a std.mixins for
Phobos that would contain meta-implementations of commonly needed
boilerplate code for mixing int
dsimcha wrote:
...
>> My suggestion is to include a mixin for unrolling loops.
>
> I thought about this. Simple loop unrolling doesn't seem like a very useful
> optimization on modern hardware because branch prediction and pipelining have
> gotten so good. It can still be useful if you also cha
== Quote from Lutger (lutger.blijdest...@gmail.com)'s article
> Instead of std.mixins, perhaps it is better to fold the code with std.typecons
> or create new modules as needed (std.pattern?).
I initially thought std.mixins would be a good idea, since it would be a
one-stop
shop for all kinds of
dsimcha wrote:
> I've been toying for a long time with the idea of a std.mixins for Phobos that
> would contain meta-implementations of commonly needed boilerplate code for
> mixing into classes and and structs. I've started to prototype it
> (http://dsource.org/projects/scrapple/browser/trunk/st
On 8/31/10 11:28 CDT, Philippe Sigaud wrote:
On Tue, Aug 31, 2010 at 17:05, Andrei Alexandrescu
mailto:seewebsiteforem...@erdani.org>>
wrote:
On 8/31/10 7:49 CDT, Michel Fortin wrote:
On 2010-08-31 06:16:17 -0400, bearophile
mailto:bearophileh...@lycos.com>> said:
On Tue, Aug 31, 2010 at 17:05, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:
> On 8/31/10 7:49 CDT, Michel Fortin wrote:
>
>> On 2010-08-31 06:16:17 -0400, bearophile said:
>>
>> If in generic code T.init is not guaranteed to be an lvalue, as your
>>> example shows, isn't it better
On Tue, 31 Aug 2010 19:13:17 +0400, Jacob Carlborg wrote:
On 2010-08-31 05:17, Andrei Alexandrescu wrote:
On 8/30/10 20:04 PDT, dsimcha wrote:
I've been toying for a long time with the idea of a std.mixins for
Phobos that
would contain meta-implementations of commonly needed boilerplate code
On 8/31/10 9:09 CDT, Torarin wrote:
2010/8/31 BCS:
Hello Torarin,
So reviews are useless?
Without context, yes they are useless. With context, your just looking at
correlation: i.e "we like/dislike the same things".
I can understand the premise of the view that art cannot be
quality-asses
On 2010-08-31 05:49, dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
On 8/30/10 20:04 PDT, dsimcha wrote:
I've been toying for a long time with the idea of a std.mixins for Phobos that
would contain meta-implementations of commonly needed boilerplate c
On 2010-08-31 05:17, Andrei Alexandrescu wrote:
On 8/30/10 20:04 PDT, dsimcha wrote:
I've been toying for a long time with the idea of a std.mixins for
Phobos that
would contain meta-implementations of commonly needed boilerplate code
for
mixing into classes and and structs. I've started to prot
On 8/31/10 7:49 CDT, Michel Fortin wrote:
On 2010-08-31 06:16:17 -0400, bearophile said:
If in generic code T.init is not guaranteed to be an lvalue, as your
example shows, isn't it better to disallow (turning it into a syntax
error) &T.init in all cases?
Personally, I'd say the code should
2010/8/31 BCS :
> Hello Torarin,
>
>> So reviews are useless?
>>
>
> Without context, yes they are useless. With context, your just looking at
> correlation: i.e "we like/dislike the same things".
I can understand the premise of the view that art cannot be
quality-assessed, but I think there are s
Steven Schveighoffer wrote:
On Mon, 30 Aug 2010 16:43:27 -0400, Kagamin wrote:
Steven Schveighoffer Wrote:
Shit, just look at the
over-abundance of totally crappy open source software versus for-sale
software.
Who cares about crap if free software is still better than for-sale?
For-sale
Wouldn't it be better if we had some kind of compile-time block
statement instead of making separate compile-time keywords for every
run-time keyword?
For example, we could reuse static, and instead of code like this from
std.range:
private template MostDerivedInputRangeImpl(R) {
private alia
31.08.2010 16:49, Michel Fortin пишет:
On 2010-08-31 06:16:17 -0400, bearophile said:
If in generic code T.init is not guaranteed to be an lvalue, as your
example shows, isn't it better to disallow (turning it into a syntax
error) &T.init in all cases?
Personally, I'd say the code should c
Hello Torarin,
So reviews are useless?
Without context, yes they are useless. With context, your just looking at
correlation: i.e "we like/dislike the same things".
2010/8/31 BCS :
Hello Kagamin,
dsimcha Wrote:
Of course everyone thinks ~60-70% of what Hollywood puts out is
crap. Th
On 2010-08-31 06:16:17 -0400, bearophile said:
If in generic code T.init is not guaranteed to be an lvalue, as your
example shows, isn't it better to disallow (turning it into a syntax
error) &T.init in all cases?
Personally, I'd say the code should check if T.init is an lvalue using
__trai
31.08.2010 0:27, Torarin wrote:
Yeah, I get the enum case, but what I forgot to mention is that the
example from move() is enclosed in
static if (is(T == struct))
Which makes me wonder what kind of struct would have an rvalue .init.
I don't know, maybe the one that's not invented yet ;)
On Mon, 30 Aug 2010 16:43:27 -0400, Kagamin wrote:
Steven Schveighoffer Wrote:
Shit, just look at the
over-abundance of totally crappy open source software versus for-sale
software.
Who cares about crap if free software is still better than for-sale?
For-sale software that sucks doesn't l
So reviews are useless?
2010/8/31 BCS :
> Hello Kagamin,
>
>> dsimcha Wrote:
>>
>>> Of course everyone thinks ~60-70% of what Hollywood puts out is crap.
>>> The problem is that everyone thinks that about a **different**
>>> ~60-70% because different movies cater to different niches. Having a
>>>
Stanislav Blinov:
> > Currently you can take its address, so doesn't that mean that it's an
> > lvalue?
>
> No, you can't. Generally, that is.
> For example:
> enum A
> {
> a,
> b
> }
>
> void main()
> {
> void* p = &A.init; // won't compile
> }
>
> You may be able to take ad
Andrei:
Sorry for my late answer, yesterday I was very busy.
>What I was saying is that in a past bug report you complained that find() is
>too hard to understand.<
An in a later post I have explained what in my opinion it can be done to
improve the situation (this is not a fully good answer,
Justin Johansson:
> "challenging D to do this or that" in the
> context of, say, another programming language or some CS
> problem.
In past months I have proposed two little challenges, the second of them was to
implement this RosettaCode task in D, to produce a program that is faster,
shorter a
59 matches
Mail list logo
