I have a proposal to introduce and optional explicit separation of
compile-time facilities from run-time facilities.
There is a new keyword, called compiletime (or something similar).
The keyword can be used with `is` expression to detect whether the current
scope is executing in compile-time or no
On Fri, 23 Sep 2011 11:51:35 -0400, Gor F. Gyolchanyan
wrote:
I have a proposal to introduce and optional explicit separation of
compile-time facilities from run-time facilities.
There is a new keyword, called compiletime (or something similar).
The keyword can be used with `is` expression to
"Steven Schveighoffer" wrote in message
news:op.v19qwjhqeav7ka@localhost.localdomain...
>
>
> All of the rest of your points are solved with static if(__ctfe)
>
> -Steve
You can't use __ctfe with static if - you can only use it where a runtime
variable would be used.
If you instantiate a variable with a function call at compile-time
then that function shouldn't be compiled in (AFAIK) unless it's
referenced elsewhere. And for disallowing user-code to use such a
function that's what access specifiers are for. The beauty of D is
that you write a function once and
About enum: it still stays. at least until D3 or so.
enum has it's own meaning too. the variable part is the least important part of
what i presented.
Not qite. __ctfe can solve many problems, but, for example, you can't use __ctfe
to determine whether you should use to!string or toStringNow.
__c
About the "write once": i agree, it's a valuable feature of D, regarding CTFE.
But there are many times, where a function can be made to be much faster if some
of it's arguments are known at compile-time.
Writing those kind of functions involves having lots of different kind of
templates with non-u
It's great that you have taken an interest in the development of D!
Some of this is already in the language in other forms (enum, for instance)
and some has been discussed before (searching the newsgroup archive for
static arguments should find it) and rejected. The bar for new language
featur
On Fri, 23 Sep 2011 12:20:21 -0400, Gor F. Gyolchanyan
wrote:
Not qite.
I apologize, you are right that __ctfe is a runtime variable, but I find
that interesting.
An optimizer will (hopefully) remove any if(__ctfe) branches, so even
though it's "evaluated at runtime", it's still evalu
Thank you so much for an objective reply! Of course i realize, that there are
more
important issues with DMD (i recently suggested not to implement enhancement
requests to free up time to fix bugs). What i suggest is, as you correctly
noticed, a very big task and i realize that it's not gonna be s
It's not a performance issue.
You can't do this:
if(_ctfe)
to!string(...);
else
toStringNow!(...);
because the toStringNow!(...) won't compile, because it's argument is not a
compile-time value.
about non-functional style templates:
When you have a complex computation in your templates,
Gor F. Gyolchanyan Wrote:
> Thank you so much for an objective reply! Of course i realize, that there are
> more
> important issues with DMD (i recently suggested not to implement enhancement
> requests to free up time to fix bugs).
I was going to say, for someone who wants to stop work on enhan
On Fri, 23 Sep 2011 14:15:25 -0400, Gor F. Gyolchanyan
wrote:
It's not a performance issue.
You can't do this:
if(_ctfe)
to!string(...);
else
toStringNow!(...);
because the toStringNow!(...) won't compile, because it's argument is
not a
compile-time value.
Well, first, I was un
Thanks! You've been extremely helpful! You're right, asking for existing
solution
before proposing a new one is much better.
I've been studying D2 for several months non-stop. I've been paying close
attention to all discussions on D newsgroups and bugfixes on every DMD release.
It's time for me t
On Friday, September 23, 2011 11:15 Gor F. Gyolchanyan wrote:
> It's not a performance issue.
> You can't do this:
>
> if(_ctfe)
> to!string(...);
> else
> toStringNow!(...);
>
> because the toStringNow!(...) won't compile, because it's argument is not a
> compile-time value.
So, use a normal fu
Of course, if the entire D gets CTFE-able, the __ctfe will be completely
useless.
But i can't see that coming for a long time. Most of the major programming
problems are best solved with classes and that's where CTFE stops.
About templates:
void unpackIntoFunction(alias arrayOfVariants, alias fu
But that will lead me to writing the same functions twice (making a template
version, actually). Again, if D becomes entirely CTFE-able, the topic can be
closed for good. :-)
On Friday, September 23, 2011 11:06 Gor F. Gyolchanyan wrote:
> Thank you so much for an objective reply! Of course i realize, that there
> are more important issues with DMD (i recently suggested not to implement
> enhancement requests to free up time to fix bugs). What i suggest is, as
> you corr
Agreed.
There are lots of dark-magic compile-time D techniques yet to be discovered.
Even C++'s templates, which are decades old, don't stop getting new usage ideas.
I'll stop making enhancement requests until I face a problem with current
language, which not even D.learn can help solve.
On anot
On 09/23/2011 08:47 PM, Gor F. Gyolchanyan wrote:
Of course, if the entire D gets CTFE-able, the __ctfe will be completely
useless.
But i can't see that coming for a long time. Most of the major programming
problems are best solved with classes and that's where CTFE stops.
About templates:
voi
On 09/23/2011 08:50 PM, Gor F. Gyolchanyan wrote:
But that will lead me to writing the same functions twice (making a template
version, actually). Again, if D becomes entirely CTFE-able, the topic can be
closed for good. :-)
What can template versions compute that normal functions cannot?
On Fri, 23 Sep 2011 14:47:32 -0400, Gor F. Gyolchanyan
wrote:
Of course, if the entire D gets CTFE-able, the __ctfe will be completely
useless.
But i can't see that coming for a long time.
Well, anywhere that it makes sense, it should be CTFE-able.
For example to!string(int) should be CT
Damn I must have missed the discussion where __ctfe was introduced.
What exactly is this new symbol for? It should be put in the docs
unless it's there already (I can't find it).
On 9/23/11, Andrej Mitrovic wrote:
> Damn I must have missed the discussion where __ctfe was introduced.
> What exactly is this new symbol for? It should be put in the docs
> unless it's there already (I can't find it).
>
Looks like it's not new, but I didn't know about it. Found this:
http://www
On Fri, 23 Sep 2011 15:38:30 -0400, Andrej Mitrovic
wrote:
Damn I must have missed the discussion where __ctfe was introduced.
What exactly is this new symbol for? It should be put in the docs
unless it's there already (I can't find it).
http://www.d-programming-language.org/function.html#i
On 9/23/11, Steven Schveighoffer wrote:
> On Fri, 23 Sep 2011 15:38:30 -0400, Andrej Mitrovic
> wrote:
>
>> Damn I must have missed the discussion where __ctfe was introduced.
>> What exactly is this new symbol for? It should be put in the docs
>> unless it's there already (I can't find it).
>
>
Gor F. Gyolchanyan , dans le message (digitalmars.D:145120), a écrit :
> Template functions will have a very convenient syntax sugar:
>
> void myFunc(int arg1, compiletime int arg2, char arg3, compiletime char arg4)
> {
> }
>
> , which is equivalent to:
>
> vodi myFunc(int arg2, int arg3)(int ar
Thanks! I thought that idea was worthless after i received lots of criticism
(healthy criticism, to be honest).
The biggest one of all is the auto compiletime, of course.
This alone would allow one to write functions, that take advantage of any
optimization opportunities and perform run-time compu
27 matches
Mail list logo
