Re: @ctfeonly

On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson wrote: I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the

Re: @ctfeonly

On Friday, 8 December 2017 at 18:59:00 UTC, Manu wrote: Nicholas wants a *compile* error, not a link error. I don't think this is necessarily implied from the original post. Certainly, a linker error would just work fine for the original use case (avoiding unsupported codegen on compute

Re: @ctfeonly

On 7 December 2017 at 19:43, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On 12/7/2017 5:20 PM, Manu wrote: > >> Right, but that's what I'm saying; using your solution of putting a >> function in a module that's not compiled to inhibit code generation won't >> inhibit

Re: @ctfeonly

On 7 December 2017 at 19:49, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On 12/7/2017 5:30 PM, Manu wrote: > >> I tried this, and was surprised it didn't work: >> >> int ctfeOnly(int x) >> { >> static assert(__ctfe); >> r

Re: @ctfeonly

On 7 December 2017 at 17:45, Nicholas Wilson via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Friday, 8 December 2017 at 01:30:13 UTC, Manu wrote: > >> I tried this, and was surprised it didn't work: >> >> int ctfeOnly(int x) >> { >&

Re: @ctfeonly

On Fri, Dec 08, 2017 at 05:53:37AM +0200, ketmar via Digitalmars-d wrote: [...] > still, why `__ctfe` was designed as variable, and not as `enum ctfe = > ;`? https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time T -- I think the conspiracy theorists are out to get us...

Re: @ctfeonly

On Fri, Dec 08, 2017 at 11:03:34AM +, Paolo Invernizzi via Digitalmars-d wrote: > On Friday, 8 December 2017 at 02:14:09 UTC, H. S. Teoh wrote: > > On Thu, Dec 07, 2017 at 07:20:57PM -0700, Jonathan M Davis via > > Digitalmars-d wrote: [...] > > > In spite of the fact that CTFE is done at

Re: @ctfeonly

? VERY good question, I'm not sure. From a purely practical perspective I'd say it should pass __traits(compiles, ...) and is-expressions purely because the kind of things that @ctfeonly would be used to cull from the produced binaries are used as is-expressions (e.g. the template lambda

Re: @ctfeonly

of things that @ctfeonly would be used to cull from the produced binaries are used as is-expressions (e.g. the template lambda that determines isInputRange), although I expect it use to be rare. Ultimately I think this this feature would fall in to the category of "use responsibly" an

Re: @ctfeonly

On Friday, 8 December 2017 at 02:14:09 UTC, H. S. Teoh wrote: On Thu, Dec 07, 2017 at 07:20:57PM -0700, Jonathan M Davis via Digitalmars-d wrote: [...] In spite of the fact that CTFE is done at compile time, __ctfe is a runtime thing - it's just that it's runtime from the perspective of CTFE.

Re: @ctfeonly

On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson wrote: I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the

Re: @ctfeonly

On Thursday, 7 December 2017 at 06:33:42 UTC, E.S. Quinn wrote: On Thursday, 7 December 2017 at 05:53:06 UTC, bauss wrote: On Thursday, 7 December 2017 at 04:45:15 UTC, Jonathan M Davis wrote: As I understand it, with the way CTFE works, it pretty much can't know whether a function can be

Re: @ctfeonly

On Friday, 8 December 2017 at 06:39:10 UTC, ketmar wrote: no compilation errors, runtime assert. that is, it is technically still executed in runtime. damnit!

Re: @ctfeonly

Mike Franklin wrote: // I couldn't figure out how to force `onlyCompileTime` to // execute at runtime. That's probably a good thing. string s = onlyCompileTime(); no compilation errors, runtime assert. that is, it is technically still executed in runtime.

Re: @ctfeonly

On Friday, 8 December 2017 at 01:30:13 UTC, Manu wrote: I tried this, and was surprised it didn't work: int ctfeOnly(int x) { static assert(__ctfe); return x + 1; } This would probably solve the problem in a satisfying way without an attribute? Interestingly, if you put `__ctfe

Re: @ctfeonly

On Friday, 8 December 2017 at 03:41:05 UTC, Walter Bright wrote: bar.d: module bar; string generateString(T)() { return T.stringof ~ " foo;"; } enum s = generateString!int(); a.d: @compute(CompileFor.deviceOnly) module a; int baz() { import bar; bar.s; return foo; } That

Re: @ctfeonly

ketmar wrote: still, why `__ctfe` was designed as variable, and not as `enum ctfe = ;`? ah, sorry, i remembered. that was stupid question. the rationale is: `static if` and `static assert` are processed *before* CTFE phase. i.e. CTFE interpreter never sees them, and cannot do the choice.

Re: @ctfeonly

ketmar wrote: still, why `__ctfe` was designed as variable, and not as `enum ctfe = ;`? p.s.: i see only one reason for this rationale: to explicitly prevent people using `static if` to separate CTFE and non-CTFE code (that is, to lessen the chance than function heaves differently in

Re: @ctfeonly

Walter Bright wrote: On 12/7/2017 5:30 PM, Manu wrote: I tried this, and was surprised it didn't work: int ctfeOnly(int x) { static assert(__ctfe); return x + 1; } The error is: test2.d(3): Error: variable __ctfe cannot be read at compile time test2.d(3):while evaluating: static

Re: @ctfeonly

On 12/7/2017 5:30 PM, Manu wrote: I tried this, and was surprised it didn't work: int ctfeOnly(int x) { static assert(__ctfe); return x + 1; } The error is: test2.d(3): Error: variable __ctfe cannot be read at compile time test2.d(3):while evaluating: static assert(__ctfe) because

Re: @ctfeonly

On 12/7/2017 5:20 PM, Manu wrote: Right, but that's what I'm saying; using your solution of putting a function in a module that's not compiled to inhibit code generation won't inhibit people from *attempting* to making runtime calls (and getting link errors)... whereas a compile error trying

Re: @ctfeonly

tains `baz` and `generatesMixin!int`. generateMixin deals with strings which are not allowed (global variables are unsupported). This would fail compilation. If `generatesMixin` were to be marked `@ctfeonly`, this would pass. bar.d: module bar; string generateString(T)() { return T.stringof ~ " f

Re: @ctfeonly

On Thu, Dec 07, 2017 at 07:20:57PM -0700, Jonathan M Davis via Digitalmars-d wrote: [...] > In spite of the fact that CTFE is done at compile time, __ctfe is a > runtime thing - it's just that it's runtime from the perspective of > CTFE. So, stuff like static if or static assert doesn't work. You

Re: @ctfeonly

ying; using your solution of putting a > > function in a module that's not compiled to inhibit code generation > > won't > > inhibit people from *attempting* to making runtime calls (and getting > > link errors)... whereas a compile error trying to runtime-call a > &g

Re: @ctfeonly

On Friday, 8 December 2017 at 01:30:13 UTC, Manu wrote: I tried this, and was surprised it didn't work: int ctfeOnly(int x) { static assert(__ctfe); return x + 1; } This would probably solve the problem in a satisfying way without an attribute? I think that's because __ctfe, despite being

Re: @ctfeonly

> inhibit people from *attempting* to making runtime calls (and getting link > errors)... whereas a compile error trying to runtime-call a function that > shouldn't be runtime-called might be more desirable. > I'm not actually registering support for @ctfeonly, just that I think it's &

Re: @ctfeonly

shouldn't be runtime-called might be more desirable. I'm not actually registering support for @ctfeonly, just that I think it's a pattern that I have wanted and should be supported in some way, and a compile-time error would be nicer than a link error.

Re: @ctfeonly

th strings which are not allowed (global variables are unsupported). This would fail compilation. If `generatesMixin` were to be marked `@ctfeonly`, this would pass.

Re: @ctfeonly

On 7 December 2017 at 03:09, lobo via Digitalmars-d wrote: > On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson wrote: >> >> I'd like to add an attribute to indicate that the annotated function is >> only available at compile time so that in cases where the

Re: @ctfeonly

time. > > > > Not bad, but that is swaying into the cumbersome category.  If > > that's the best we can do, a @ctfeonly attribute starts looking > > pretty good. > > More and more attributes to do essentially trivial things is > cumbersomeness all on its

Re: @ctfeonly

hout, and in those cases > something like @ctfeonly wouldn't make any sense. In my experience, > pretty much the only time that something like @ctfeonly would make > any sense would be with a function for generating a string mixin. Not only string mixins. When programming for microcontrol

Re: @ctfeonly

Am Wed, 06 Dec 2017 20:18:57 -0700 schrieb Jonathan M Davis : > Folks have talked about all kinds of template code and stuff being > kept around in binaries even though it was only used at compile time > (e.g. stuff like isInputRange), but I don't know how much that's

Re: @ctfeonly

e whole module as @nogc. @nogc checking is done in semantic phase, so it will still error about GC usage in functions which later turn out to be only used in CTFE. Detecting this in the linker or compiler backend is too late. So we'd have to detect unexported, unused private functions in sema

Re: @ctfeonly

be called at compile time until it tries, but a unit test can catch it if the function no longer works at compile time. Not bad, but that is swaying into the cumbersome category.  If that's the best we can do, a @ctfeonly attribute starts looking pretty good. More and more attributes to do

Re: @ctfeonly

On 12/7/2017 2:07 AM, Nicholas Wilson wrote: Doesn't work for templates. I don't know how your code is organized, but if the template is instantiated in another file, it won't have code generated for it either.

Re: @ctfeonly

On 12/7/2017 11:41 AM, Manu wrote: Misuse of the API; ie, a runtime call, will result in an unsuspecting user getting a surprising link error, rather than a nice compile-time error explaining what they did wrong... I think Nicholas is talking about functions for which code cannot be

Re: @ctfeonly

On 7 December 2017 at 01:34, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On 12/6/2017 5:21 PM, Nicholas Wilson wrote: > >> I'd like to add an attribute to indicate that the annotated function is >> only available at compile time so that in cases where the operation is

Re: @ctfeonly

On Thursday, 7 December 2017 at 09:34:51 UTC, Walter Bright wrote: On 12/6/2017 5:21 PM, Nicholas Wilson wrote: I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and

Re: @ctfeonly

On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson wrote: I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the

Re: @ctfeonly

On 12/6/2017 5:21 PM, Nicholas Wilson wrote: I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the result is only used at

Re: @ctfeonly

th the way CTFE works, > > it pretty much can't know whether a function can be called at > > compile time until it tries, but a unit test can catch it if > > the function no longer works at compile time. > > Not bad, but that is swaying into the cumbersome category. If > that's

Re: @ctfeonly

On Thursday, 7 December 2017 at 06:33:42 UTC, E.S. Quinn wrote: If all you need is a runtime error, you can already put assert(__ctfe); in your function. For me, a runtime error is exactly what I want to avoid. Mike

Re: @ctfeonly

, but a unit test can catch it if the function no longer works at compile time. Not bad, but that is swaying into the cumbersome category. If that's the best we can do, a @ctfeonly attribute starts looking pretty good. Mike

Re: @ctfeonly

On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson wrote: I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the

Re: @ctfeonly

On Thursday, 7 December 2017 at 05:53:06 UTC, bauss wrote: On Thursday, 7 December 2017 at 04:45:15 UTC, Jonathan M Davis wrote: As I understand it, with the way CTFE works, it pretty much can't know whether a function can be called at compile time until it tries - Jonathan M Davis I think

Re: @ctfeonly

On Thursday, 7 December 2017 at 04:45:15 UTC, Jonathan M Davis wrote: As I understand it, with the way CTFE works, it pretty much can't know whether a function can be called at compile time until it tries - Jonathan M Davis I think that's the point of the attribute. You tell the compiler

Re: @ctfeonly

On Thursday, December 07, 2017 03:43:42 Nicholas Wilson via Digitalmars-d wrote: > On Thursday, 7 December 2017 at 03:18:57 UTC, Jonathan M Davis > > wrote: > > On Thursday, December 07, 2017 02:09:56 lobo via Digitalmars-d > > > > wrote: > >> On Thursday, 7 December 2017 at 01:21:11 UTC,

Re: @ctfeonly

On Thursday, December 07, 2017 03:59:09 Mike Franklin via Digitalmars-d wrote: > Also, I want the > compiler to let me know if my intended-for-compile-time-only > function cannot be used at compile-time because I mistakenly made > it dependent on something that is only available at runtime. The

Re: @ctfeonly

On Thursday, 7 December 2017 at 03:43:42 UTC, Nicholas Wilson wrote: ... Do you have any other ideas about how to achieve this other than an attribute? Having an attribute seems the most simple and straightforward. llvm has "Aggressive Dead Code Elimination"- and "Dead Code

Re: @ctfeonly

ketmar wrote: Nicholas Wilson wrote: Also not generating the code in the first place means less I/O for the compiler and less work for the linker. this is solvable without any additional flags, tho: compiler should just skip codegen phase for any function that is not referenced by another

Re: @ctfeonly

A: https://issues.dlang.org/show_bug.cgi?id=14758). I don't yet see how @ctfeonly would help with that. Mike

Re: @ctfeonly

Nicholas Wilson wrote: Also not generating the code in the first place means less I/O for the compiler and less work for the linker. this is solvable without any additional flags, tho: compiler should just skip codegen phase for any function that is not referenced by another compiled function

Re: @ctfeonly

On Thursday, 7 December 2017 at 03:18:57 UTC, Jonathan M Davis wrote: On Thursday, December 07, 2017 02:09:56 lobo via Digitalmars-d wrote: On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson wrote: > I'd like to add an attribute to indicate that the annotated > function is only

Re: @ctfeonly

at compile-time. Since they are nested inside the template, they do quickly add up to a lot of dead code in the executable. Having a @ctfeonly annotation that tells the compiler not to codegen the (many instantiations of the) function would be greatly welcomed. T this is a hack for something

Re: @ctfeonly

On Thursday, December 07, 2017 02:09:56 lobo via Digitalmars-d wrote: > On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson > > wrote: > > I'd like to add an attribute to indicate that the annotated > > function is only available at compile time so that in cases > > where the operation

Re: @ctfeonly

this as a standard thing? I'd like to have this too. Some of my template-heavy code use a good number of CTFE-only functions that are only called at compile-time. Since they are nested inside the template, they do quickly add up to a lot of dead code in the executable. Having a @ctfeonly annotation

Re: @ctfeonly

On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson wrote: I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the

Re: @ctfeonly

d > would benefit having this as a standard thing? I'd like to have this too. Some of my template-heavy code use a good number of CTFE-only functions that are only called at compile-time. Since they are nested inside the template, they do quickly add up to a lot of dead code in the executable. Having a @ctf

@ctfeonly

I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the result is only used at compile time (for a mixin) the compiler is free to

Re: @ctfeonly

On Thursday, 7 December 2017 at 01:18:04 UTC, Nicholas Wilson wrote: I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the

@ctfeonly

I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the result is only used at compile time (for a mixin) the compiler is free to