On 02.09.2017 01:37, Q. Schroll wrote:
On Friday, 1 September 2017 at 23:13:50 UTC, Q. Schroll wrote:
[..]
Just as Scott Meyers said: make it easy to use correctly and hard to
use incorrectly. Today it's easy to use incorrectly.
While
enum foo = [1,2,3];
assert(foo is foo);
fails,
en
On 02.09.2017 01:13, Q. Schroll wrote:
On Friday, 1 September 2017 at 21:08:20 UTC, Ali Çehreli wrote:
[snip]
> assert(!([1,2,3] is [1,2,3]));
>
> Which is exactly what enum expands to and totally expected.
Where is the
> surprise?
This is not a surprise. Array literals are not identical.
In
On Friday, 1 September 2017 at 23:13:50 UTC, Q. Schroll wrote:
[..]
Just as Scott Meyers said: make it easy to use correctly and
hard to use incorrectly. Today it's easy to use incorrectly.
While
enum foo = [1,2,3];
assert(foo is foo);
fails,
enum bla = "123";
assert(foo is foo);
passe
On 01.09.2017 20:48, Dmitry Olshansky wrote:
On Thursday, 31 August 2017 at 14:28:57 UTC, Ali Çehreli wrote:
On 08/31/2017 01:52 AM, Nicholas Wilson wrote:
I think Timon is referring to:
enum int[] foo = [1,2,3];
auto bar = foo;
auto baz = foo;
assert(!(bar is baz)); // Passes
Even better
On Friday, 1 September 2017 at 21:08:20 UTC, Ali Çehreli wrote:
[snip]
> assert(!([1,2,3] is [1,2,3]));
>
> Which is exactly what enum expands to and totally expected.
Where is the
> surprise?
This is not a surprise. Array literals are not identical.
In the surprising case foo is a symbol, see
On 09/01/2017 11:48 AM, Dmitry Olshansky wrote:
> On Thursday, 31 August 2017 at 14:28:57 UTC, Ali Çehreli wrote:
>> On 08/31/2017 01:52 AM, Nicholas Wilson wrote:
>>
>>> I think Timon is referring to:
>>>
>>> enum int[] foo = [1,2,3];
>>>
>>> auto bar = foo;
>>> auto baz = foo;
>>>
>>> assert(!(b
On Thursday, 31 August 2017 at 14:28:57 UTC, Ali Çehreli wrote:
On 08/31/2017 01:52 AM, Nicholas Wilson wrote:
I think Timon is referring to:
enum int[] foo = [1,2,3];
auto bar = foo;
auto baz = foo;
assert(!(bar is baz)); // Passes
Even better:
enum int[] foo = [1,2,3];
assert(!(
On 08/31/2017 01:52 AM, Nicholas Wilson wrote:
I think Timon is referring to:
enum int[] foo = [1,2,3];
auto bar = foo;
auto baz = foo;
assert(!(bar is baz)); // Passes
Even better:
enum int[] foo = [1,2,3];
assert(!(foo is foo)); // Passes
Ali
On Thursday, 31 August 2017 at 08:40:03 UTC, Dmitry Olshansky
wrote:
On Wednesday, 30 August 2017 at 12:28:10 UTC, Timon Gehr wrote:
On 30.08.2017 11:36, Dmitry Olshansky wrote:
The subj is not (any longer) supported by compiler. In fact
it used to produce wrong code sometimes and now it just
On Wednesday, 30 August 2017 at 12:28:10 UTC, Timon Gehr wrote:
On 30.08.2017 11:36, Dmitry Olshansky wrote:
The subj is not (any longer) supported by compiler. In fact it
used to produce wrong code sometimes and now it just plainly
rejects it.
[..]
I think the underlying reason why it doe
{
@property auto getRe(){ return staticRe; }
alias getRe this;
}
enum wrapper = Wrapper();
}
public enum ctRegex(alias pattern, alias flags=[]) =
ctRegexImpl!(pattern, flags).wrapper;
Now ctRegex returns a neat forwarding struct that bypasses the strange
limitation. The
icRe; }
alias getRe this;
}
enum wrapper = Wrapper();
}
public enum ctRegex(alias pattern, alias flags=[]) =
ctRegexImpl!(pattern, flags).wrapper;
Now ctRegex returns a neat forwarding struct that bypasses the
strange limitation. The question remains though - why can't
compiler do it automatically?
On Monday, 19 January 2015 at 10:49:52 UTC, Walter Bright wrote:
On 1/18/2015 8:23 PM, deadalnix wrote:
IMO style is the role of the formater. Prompting the
programmer with "don't
write this, write that instead" only crate reaction à la "If
you know what I
meant, why don't you compile that you
On 1/17/15 3:33 AM, deadalnix wrote:
This is accepted :
auto fun(T)(T T) inout if(...) { ... }
This is not :
auto fun(T)(T T) if(...) inout { ... }
Is there a reason ?
I kind of agree with you. Because this is short for:
template fun(T) if(...) { auto fun(T t) inout {...}}
I think it makes
On 1/18/15 10:57 PM, Walter Bright wrote:
On 1/18/2015 7:07 PM, deadalnix wrote:
On Monday, 19 January 2015 at 02:24:00 UTC, Walter Bright wrote:
On 1/18/2015 12:46 AM, Brian Schott wrote:
On Sunday, 18 January 2015 at 08:40:19 UTC, Walter Bright wrote:
Sounds like a good idea. If I wasn't cl
On 1/18/2015 8:23 PM, deadalnix wrote:
IMO style is the role of the formater. Prompting the programmer with "don't
write this, write that instead" only crate reaction à la "If you know what I
meant, why don't you compile that you asshole ?"
Redundancy is built in to the language design on purpo
On Monday, 19 January 2015 at 03:57:14 UTC, Walter Bright wrote:
No. Constraints belong after the template declaration, not
embedded in the template's implementation.
Furthermore, there's no useful purpose to enabling style wars
and then requiring people to put one way in their coding
standar
On 1/18/2015 7:07 PM, deadalnix wrote:
On Monday, 19 January 2015 at 02:24:00 UTC, Walter Bright wrote:
On 1/18/2015 12:46 AM, Brian Schott wrote:
On Sunday, 18 January 2015 at 08:40:19 UTC, Walter Bright wrote:
Sounds like a good idea. If I wasn't clear, I think that class change was a
mistak
On Monday, 19 January 2015 at 02:24:00 UTC, Walter Bright wrote:
On 1/18/2015 12:46 AM, Brian Schott wrote:
On Sunday, 18 January 2015 at 08:40:19 UTC, Walter Bright
wrote:
Sounds like a good idea. If I wasn't clear, I think that
class change was a
mistake.
Now that I see from that pull requ
On 1/18/2015 12:16 AM, Daniel Murphy wrote:
"Walter Bright" wrote in message news:m9fodo$18lu$1...@digitalmars.com...
I don't really know where the class change came from :-(
https://github.com/D-Programming-Language/dmd/pull/1227
Thanks for digging it up. I see I missed that one.
On 1/18/2015 12:46 AM, Brian Schott wrote:
On Sunday, 18 January 2015 at 08:40:19 UTC, Walter Bright wrote:
Sounds like a good idea. If I wasn't clear, I think that class change was a
mistake.
Now that I see from that pull request that the ugly syntax was the original, I'm
not so sure. The dfi
On Saturday, January 17, 2015 08:33:49 deadalnix via Digitalmars-d wrote:
> This is accepted :
> auto fun(T)(T T) inout if(...) { ... }
>
> This is not :
> auto fun(T)(T T) if(...) inout { ... }
>
> Is there a reason ?
Well, inout is part of the signature. It's debatable as to whether the
template
On Sunday, 18 January 2015 at 08:40:19 UTC, Walter Bright wrote:
Sounds like a good idea. If I wasn't clear, I think that class
change was a mistake.
Now that I see from that pull request that the ugly syntax was
the original, I'm not so sure. The dfix feature I'm planning is
to convert
cla
On 1/17/2015 11:52 PM, Brian Schott wrote:
On Sunday, 18 January 2015 at 07:47:04 UTC, Walter Bright wrote:
On 1/17/2015 5:33 PM, deadalnix wrote:
You are basically telling me that consistency matter. If so, we either rollback
the class case, or go forward on that one.
I don't really know whe
"Walter Bright" wrote in message news:m9fodo$18lu$1...@digitalmars.com...
I don't really know where the class change came from :-(
https://github.com/D-Programming-Language/dmd/pull/1227
On Sunday, 18 January 2015 at 07:47:04 UTC, Walter Bright wrote:
On 1/17/2015 5:33 PM, deadalnix wrote:
You are basically telling me that consistency matter. If so,
we either rollback
the class case, or go forward on that one.
I don't really know where the class change came from :-(
I could
On 1/17/2015 5:33 PM, deadalnix wrote:
On Sunday, 18 January 2015 at 00:19:47 UTC, Walter Bright wrote:
On the other hand, I think having only one way to do it is better for
consistency and stylistic reasons.
For example, I never liked that:
int short unsigned
is valid in C. I don't belie
On Sunday, 18 January 2015 at 00:19:47 UTC, Walter Bright wrote:
On the other hand, I think having only one way to do it is
better for consistency and stylistic reasons.
For example, I never liked that:
int short unsigned
is valid in C. I don't believe it adds value.
You are basically t
On 1/17/2015 4:06 PM, deadalnix wrote:
Because I can never remember which one it is and run into the wrong case 50% of
the time. I'd assume that I'm not the only one, but, as I have done for ages, do
not consider this as an issue big enough to complain. This is the kind of thing
that drain you pr
On Saturday, 17 January 2015 at 21:15:53 UTC, Walter Bright wrote:
On 1/17/2015 8:56 AM, deadalnix wrote:
On Saturday, 17 January 2015 at 10:05:29 UTC, Walter Bright
wrote:
On 1/17/2015 12:33 AM, deadalnix wrote:
This is accepted :
auto fun(T)(T T) inout if(...) { ... }
This is not :
auto fun
Walter Bright:
Sure, but you'll need a rationale that is better than "why not"
:-)
Often in a language it's a good idea to have only one way to do
something. To have two places to put those attributes generates
the question: where do you want to put them? And it's a question
that wastes tim
On 1/17/2015 8:56 AM, deadalnix wrote:
On Saturday, 17 January 2015 at 10:05:29 UTC, Walter Bright wrote:
On 1/17/2015 12:33 AM, deadalnix wrote:
This is accepted :
auto fun(T)(T T) inout if(...) { ... }
This is not :
auto fun(T)(T T) if(...) inout { ... }
Is there a reason ?
There was no k
On Sat, 17 Jan 2015 17:34:21 +
deadalnix via Digitalmars-d wrote:
> On Saturday, 17 January 2015 at 17:08:12 UTC, ketmar via
> Digitalmars-d wrote:
> > sure i have. i made alot of patches to the parser, so i know
> > how it
> > is written. to make this work parser need to be changed not
>
On Saturday, 17 January 2015 at 17:08:12 UTC, ketmar via
Digitalmars-d wrote:
sure i have. i made alot of patches to the parser, so i know
how it
is written. to make this work parser need to be changed not
less than
to accept '@' before `pure`, `nothrow` and so on, and this
change was
rejected
On Sat, 17 Jan 2015 16:55:31 +
deadalnix via Digitalmars-d wrote:
> On Saturday, 17 January 2015 at 16:02:16 UTC, ketmar via
> Digitalmars-d wrote:
> > On Sat, 17 Jan 2015 08:33:49 +
> > deadalnix via Digitalmars-d wrote:
> >
> >> This is accepted :
> >> auto fun(T)(T T) inout if(...) {
On Saturday, 17 January 2015 at 10:05:29 UTC, Walter Bright wrote:
On 1/17/2015 12:33 AM, deadalnix wrote:
This is accepted :
auto fun(T)(T T) inout if(...) { ... }
This is not :
auto fun(T)(T T) if(...) inout { ... }
Is there a reason ?
There was no known reason to.
Is that possible to ma
On Saturday, 17 January 2015 at 16:02:16 UTC, ketmar via
Digitalmars-d wrote:
On Sat, 17 Jan 2015 08:33:49 +
deadalnix via Digitalmars-d wrote:
This is accepted :
auto fun(T)(T T) inout if(...) { ... }
This is not :
auto fun(T)(T T) if(...) inout { ... }
Is there a reason ?
the first is
On Sat, 17 Jan 2015 08:33:49 +
deadalnix via Digitalmars-d wrote:
> This is accepted :
> auto fun(T)(T T) inout if(...) { ... }
>
> This is not :
> auto fun(T)(T T) if(...) inout { ... }
>
> Is there a reason ?
the first is easier to parse, and i it's looking better. the second is
just unne
On 17.01.15 09:33, deadalnix wrote:
This is accepted :
auto fun(T)(T T) inout if(...) { ... }
This is not :
auto fun(T)(T T) if(...) inout { ... }
Is there a reason ?
I think it improves readability. A little :)
Often user don't care to read if-part.
On 1/17/2015 12:33 AM, deadalnix wrote:
This is accepted :
auto fun(T)(T T) inout if(...) { ... }
This is not :
auto fun(T)(T T) if(...) inout { ... }
Is there a reason ?
There was no known reason to.
This is accepted :
auto fun(T)(T T) inout if(...) { ... }
This is not :
auto fun(T)(T T) if(...) inout { ... }
Is there a reason ?
On Thursday, 9 May 2013 at 12:42:25 UTC, Anonimous wrote:
Sorry,I ment that it's an important bug,but maybe everybody was
busy
with dconf and just didn't do anything with it.
Yep, things are only slowly getting back to normality as jet lag
wears off and the recordings are taken care of… ;)
On Thursday, 9 May 2013 at 12:36:36 UTC, David Nadlinger wrote:
On Tuesday, 30 April 2013 at 00:04:04 UTC, David Eagen wrote:
On Saturday, 27 April 2013 at 17:42:54 UTC, Idan Arye wrote:
The way it works now, is that if the size is too big they use
a reference instead:
https://github.com/D-Pro
On Tuesday, 30 April 2013 at 00:04:04 UTC, David Eagen wrote:
On Saturday, 27 April 2013 at 17:42:54 UTC, Idan Arye wrote:
The way it works now, is that if the size is too big they use
a reference instead:
https://github.com/D-Programming-Language/phobos/blob/master/std/variant.d#L544#L555
So
On Tuesday, 30 April 2013 at 00:04:04 UTC, David Eagen wrote:
On Saturday, 27 April 2013 at 17:42:54 UTC, Idan Arye wrote:
The way it works now, is that if the size is too big they use
a reference instead:
https://github.com/D-Programming-Language/phobos/blob/master/std/variant.d#L544#L555
So
On Saturday, 27 April 2013 at 17:42:54 UTC, Idan Arye wrote:
The way it works now, is that if the size is too big they use a
reference instead:
https://github.com/D-Programming-Language/phobos/blob/master/std/variant.d#L544#L555
So is the bug in std.concurrency and they way it uses Variant or
On Saturday, 27 April 2013 at 11:37:38 UTC, Tavi Cacina wrote:
is it a bug the fact that a Variant may be initialized with a
struct bigger than 32 bytes? Even if this does function, it is
not consistent because you can not assign such an 'inflated'
variant to another one, assertion. This affect
is it a bug the fact that a Variant may be initialized with a
struct bigger than 32 bytes? Even if this does function, it is
not consistent because you can not assign such an 'inflated'
variant to another one, assertion. This affects the max size of a
std.concurrency message (right now it is no
r to me that the result of a calculation cannot change its type depending
on the exact magnitudes of the operands, that I interpreted ^^ as *g* or :p.
"Ha! Ha! Limitation!"
Considering that you probably have more experience with higher-level languages,
where the actual data type can be more
On 04/27/2012 03:55 AM, James Miller wrote:
On Friday, 27 April 2012 at 00:56:13 UTC, Tryo[17] wrote:
D provides an auto type facility that determins which the type
that can best accommodate a particular value. What prevents
the from determining that the only type that can accommodate
that valu
On Friday, 27 April 2012 at 00:56:13 UTC, Tryo[17] wrote:
D provides an auto type facility that determins which the type
that can best accommodate a particular value. What prevents
the from determining that the only type that can accommodate
that value is a BigInt? The same way it decides betwee
On Tuesday, 24 April 2012 at 22:45:37 UTC, Marco Leise wrote:
Am Wed, 25 Apr 2012 06:00:31 +0900
schrieb "Tyro[17]" :
I believe the following two lines of code should produce the
same output. Is there a specific reason why doesn't allow
this? Of course the only way to store the result would be
On Tuesday, 24 April 2012 at 22:45:37 UTC, Marco Leise wrote:
Am Wed, 25 Apr 2012 06:00:31 +0900
schrieb "Tyro[17]" :
I believe the following two lines of code should produce the
same output. Is there a specific reason why doesn't allow
this? Of course the only way to store the result would be
On 24/04/12 23:00, Tyro[17] wrote:
I believe the following two lines of code should produce the same
output. Is there a specific reason why doesn't allow this? Of course the
only way to store the result would be to put in into a BigInt variable
or convert it to string but I don't that shouldn't p
Marco Leise:
If you need this functionality use a programming language that
has type classes and seamlessly switches between int/BigInt
types, but drops the systems language attribute.
I think Lisp (that beside allowing you to use fixnums that can't
grow, often is used with tagged integers,
Am Wed, 25 Apr 2012 06:00:31 +0900
schrieb "Tyro[17]" :
> I believe the following two lines of code should produce the same
> output. Is there a specific reason why doesn't allow this? Of course the
> only way to store the result would be to put in into a BigInt variable
> or convert it to stri
I believe the following two lines of code should produce the same
output. Is there a specific reason why doesn't allow this? Of course the
only way to store the result would be to put in into a BigInt variable
or convert it to string but I don't that shouldn't prevent the compiler
from producin
On 1/17/12 6:59 AM, Don Clugston wrote:
On 17/01/12 10:40, Jonathan M Davis wrote:
On Tuesday, January 17, 2012 05:04:39 Timon Gehr wrote:
I don't know exactly, since @safe is neither fully specified nor
implemented. In my understanding, in @safe code, operations that may
lead to memory corrupt
On 17/01/12 10:40, Jonathan M Davis wrote:
On Tuesday, January 17, 2012 05:04:39 Timon Gehr wrote:
I don't know exactly, since @safe is neither fully specified nor
implemented. In my understanding, in @safe code, operations that may
lead to memory corruption are forbidden. Pointer - pointer cann
On Tuesday, January 17, 2012 05:04:39 Timon Gehr wrote:
> I don't know exactly, since @safe is neither fully specified nor
> implemented. In my understanding, in @safe code, operations that may
> lead to memory corruption are forbidden. Pointer - pointer cannot, other
> kinds of pointer arithmetic
Mail Mantis writes:
> 2012/1/17 Vladimir Panteleev :
>> On Tuesday, 17 January 2012 at 01:44:37 UTC, Vladimir Panteleev wrote:
>>>
>>> On Monday, 16 January 2012 at 19:28:42 UTC, Jerry wrote:
As far as I can tell, the only way to do this would be to capture every
chunk of text, the
On 01/17/2012 05:00 AM, Nick Sabalausky wrote:
"Timon Gehr" wrote in message
news:jf2p5d$2ria$1...@digitalmars.com...
On 01/17/2012 04:03 AM, Nick Sabalausky wrote:
"Vladimir Panteleev" wrote in message
news:klzeekkilpzwmjmku...@dfeed.kimsufi.thecybershadow.net...
On Tuesday, 17 January 201
"Timon Gehr" wrote in message
news:jf2p5d$2ria$1...@digitalmars.com...
> On 01/17/2012 04:03 AM, Nick Sabalausky wrote:
>> "Vladimir Panteleev" wrote in message
>> news:klzeekkilpzwmjmku...@dfeed.kimsufi.thecybershadow.net...
>>> On Tuesday, 17 January 2012 at 01:44:37 UTC, Vladimir Panteleev wr
On 01/17/2012 04:03 AM, Nick Sabalausky wrote:
"Vladimir Panteleev" wrote in message
news:klzeekkilpzwmjmku...@dfeed.kimsufi.thecybershadow.net...
On Tuesday, 17 January 2012 at 01:44:37 UTC, Vladimir Panteleev wrote:
On Monday, 16 January 2012 at 19:28:42 UTC, Jerry wrote:
As far as I can te
2012/1/17 Vladimir Panteleev :
> On Tuesday, 17 January 2012 at 01:44:37 UTC, Vladimir Panteleev wrote:
>>
>> On Monday, 16 January 2012 at 19:28:42 UTC, Jerry wrote:
>>>
>>> As far as I can tell, the only way to do this would be to capture every
>>> chunk of text, then iterate to determine the off
"Vladimir Panteleev" wrote in message
news:klzeekkilpzwmjmku...@dfeed.kimsufi.thecybershadow.net...
> On Tuesday, 17 January 2012 at 01:44:37 UTC, Vladimir Panteleev wrote:
>> On Monday, 16 January 2012 at 19:28:42 UTC, Jerry wrote:
>>> As far as I can tell, the only way to do this would be to ca
2012/1/17 Mail Mantis :
> Correct me if I'm wrong, but wouldn't this be better:
> (m_captures[1].ptr - s.ptr) / s[0].sizeof;
No, it wouldn't. Somehow, I forgot the rules for pointer ariphmetics. Sorry.
"Vladimir Panteleev" writes:
> On Tuesday, 17 January 2012 at 01:44:37 UTC, Vladimir Panteleev wrote:
>> On Monday, 16 January 2012 at 19:28:42 UTC, Jerry wrote:
>>> As far as I can tell, the only way to do this would be to capture every
>>> chunk of text, then iterate to determine the offsets.
>
On Tuesday, 17 January 2012 at 01:44:37 UTC, Vladimir Panteleev
wrote:
On Monday, 16 January 2012 at 19:28:42 UTC, Jerry wrote:
As far as I can tell, the only way to do this would be to
capture every chunk of text, then iterate to determine the
offsets.
Not sure if this is what you were refer
On Monday, 16 January 2012 at 19:28:42 UTC, Jerry wrote:
As far as I can tell, the only way to do this would be to
capture every chunk of text, then iterate to determine the
offsets.
Not sure if this is what you were referring to, but you can do...
m.pre.length + m.captures[1].ptr - m.hit.ptr
Hi all,
In general, I'm enjoying the regex respin. However, I ran into one
issue that seems to have no clean workaround.
Generally, I want to be able to get the start and end indices of
matches. With the complete match, this info can be pieced together with
match.pre().length and match.hit.leng
On Tuesday 19 October 2010 12:13:19 Graham Fawcett wrote:
> Hi Jonathan,
>
> On Mon, 18 Oct 2010 18:02:58 -0700, Jonathan M Davis wrote:
> > On Monday, October 18, 2010 17:54:50 Nick Sabalausky wrote:
> >> "Jonathan M Davis" wrote in message
> >> news:mailman.715.1287449256.858.digitalmar...@pure
Hi Jonathan,
On Mon, 18 Oct 2010 18:02:58 -0700, Jonathan M Davis wrote:
> On Monday, October 18, 2010 17:54:50 Nick Sabalausky wrote:
>> "Jonathan M Davis" wrote in message
>> news:mailman.715.1287449256.858.digitalmar...@puremagic.com...
>>
>> > One word: monads.
>> >
>> > Now, to get monads
On Mon, 18 Oct 2010 20:07:16 -0400, Nick Sabalausky wrote:
I don't know if others have noticed this before, but I think I've found a
notable limitation in D's metaprogramming potential: There doesn't
appear to
be a way to have mutable global state at compile-time.
Ch
On Monday 18 October 2010 18:49:41 bearophile wrote:
> Jonathan M Davis:
> > You can think of a monad as an extra parameter which is passed to each
> > function and holds the global state. It isn't a hole in purity at all.
> > For instance, it's how Haskell manages to have I/O and yet be
> > functi
bearophile Wrote:
> Jonathan M Davis:
>
> > You can think of a monad as an extra parameter which is passed to each
> > function
> > and holds the global state. It isn't a hole in purity at all. For instance,
> > it's
> > how Haskell manages to have I/O and yet be functionally pure. You don't
Jonathan M Davis:
> You can think of a monad as an extra parameter which is passed to each
> function
> and holds the global state. It isn't a hole in purity at all. For instance,
> it's
> how Haskell manages to have I/O and yet be functionally pure. You don't need
> the
> compiler's help to
On Monday, October 18, 2010 17:54:50 Nick Sabalausky wrote:
> "Jonathan M Davis" wrote in message
> news:mailman.715.1287449256.858.digitalmar...@puremagic.com...
>
> > One word: monads.
> >
> > Now, to get monads to work, you're going to have to be fairly organized
> > about
> > it, but that wo
"Jonathan M Davis" wrote in message
news:mailman.715.1287449256.858.digitalmar...@puremagic.com...
>
> One word: monads.
>
> Now, to get monads to work, you're going to have to be fairly organized
> about
> it, but that would be the classic solution to not being able to have or
> alter
> global
On Monday, October 18, 2010 17:07:16 Nick Sabalausky wrote:
> I don't know if others have noticed this before, but I think I've found a
> notable limitation in D's metaprogramming potential: There doesn't appear
> to be a way to have mutable global state at
On Tue, 19 Oct 2010 04:07:16 +0400, Nick Sabalausky wrote:
I don't know if others have noticed this before, but I think I've found a
notable limitation in D's metaprogramming potential: There doesn't
appear to
be a way to have mutable global state at compile-time.
Ch
Nick Sabalausky:
> The goal of this challenge is to define a global-level manifest constant
> enum that holds a value that has been incremented from multiple modules:
And I hope people will try to solve it!
So if someone solves it, we can later patch that bug ;-)
Bye,
bearophile
I don't know if others have noticed this before, but I think I've found a
notable limitation in D's metaprogramming potential: There doesn't appear to
be a way to have mutable global state at compile-time.
Challange:
Create two..."things"...they can be functions
83 matches
Mail list logo
