You missed the point. The case with dynamic libraries is just too
obvious: they're "dynamic" for a reason. The case of base classes not
knowing their derived classes is also kinda obvious because the
mutable aliases would allow for derived classes to add themselves to
the tuple by mixin in some com
On Thursday, December 29, 2011 10:23:11 Gor Gyolchanyan wrote:
> The mutability of compile-time data would essentially enable fully
> imperative compile-time computation. Right now it's almost purely
> functional with the small exception of CTFE functions. Sometimes
> functional style can't do the
The mutability of compile-time data would essentially enable fully
imperative compile-time computation. Right now it's almost purely
functional with the small exception of CTFE functions. Sometimes
functional style can't do the trick. For instance, you can't make a
template which "returns" a TypeTu
David Nadlinger wrote:
> Could you show a few examples? I'm just curious, because I wrote a
> sizable chunk of D code, often incorporating some form of compile time
> magic, and never felt the need for it.
I'd rather avoid that because code i'm writing isn't a state of art, so you
might neglect my
On 12/29/11 6:18 AM, Mariusz Gliwiński wrote:
Andrei Alexandrescu wrote:
I don't think such a feature has a huge potential use. I honestly think
it's a "meh" feature. It's a feature for defining elaborate literals,
and for that we have the shock and awe of mixin and CTFE.
Actually, i already n
On 12/28/2011 9:18 PM, Mariusz Gliwiński wrote:
For me, question would be not "if it's useful", but "is it easy to implement
and if it's not hurting compiler performance too much".
I beg to differ. A feature should be "why", not "why not". Otherwise, we wind up
with a complex boatload of semi-
Andrei Alexandrescu wrote:
> I don't think such a feature has a huge potential use. I honestly think
> it's a "meh" feature. It's a feature for defining elaborate literals,
> and for that we have the shock and awe of mixin and CTFE.
Actually, i already needed it few times in my D project (and stil
On 12/28/11 4:54 PM, Gor Gyolchanyan wrote:
I think you are, because this depends on syntax; blank lines between
them would break it. Still there would be a huge potential use for
that feature.
I don't think such a feature has a huge potential use. I honestly think
it's a "meh" feature. It's a
On Wed, 28 Dec 2011 19:51:42 +0100, Andrei Alexandrescu
wrote:
On 12/28/11 12:22 PM, Martin Nowak wrote:
On Wed, 28 Dec 2011 15:00:10 +0100, Gor Gyolchanyan
wrote:
This is something I was thinking about for a long time now.
There seems to be absolutely no difference between T, const(T) a
I think you are, because this depends on syntax; blank lines between
them would break it. Still there would be a huge potential use for
that feature.
On Wed, Dec 28, 2011 at 10:51 PM, Andrei Alexandrescu
wrote:
> On 12/28/11 12:22 PM, Martin Nowak wrote:
>>
>> On Wed, 28 Dec 2011 15:00:10 +0100,
On 12/28/11 12:22 PM, Martin Nowak wrote:
On Wed, 28 Dec 2011 15:00:10 +0100, Gor Gyolchanyan
wrote:
This is something I was thinking about for a long time now.
There seems to be absolutely no difference between T, const(T) and
immutable(T) if T is a compile-time value (a enum or a local in C
On Wed, 28 Dec 2011 15:00:10 +0100, Gor Gyolchanyan
wrote:
This is something I was thinking about for a long time now.
There seems to be absolutely no difference between T, const(T) and
immutable(T) if T is a compile-time value (a enum or a local in CTFE).
The possibility to mutate compile-t
This is something I was thinking about for a long time now.
There seems to be absolutely no difference between T, const(T) and
immutable(T) if T is a compile-time value (a enum or a local in CTFE).
The possibility to mutate compile-time values (at compile time, of
course) would allow very convenie
13 matches
Mail list logo
