On Friday, 8 December 2017 at 10:46:20 UTC, John Colvin 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 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 not codegen that function.
>>
>> I can add this to LDC pretty easily, but does anyone else have a use for this (e.g. shrinking binary sizes for mixin heavy codebases) and would benefit having this as a standard thing?
>
> How would such a thing interact with __traits(compiles, ...) and is-expressions?

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 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" and it would be the responsibility of the user. They could always reflect on the presence of the attribute if need be.

From a point of consistency, probably however semantic constraints on things like LDC's magic attributes are done. I'm not sure how that is handled, but I suspect that __traits(compiles,...) does not take it into account. Johan?

I will think more on it.

Thanks.

On Friday, 8 December 2017 at 11:48:26 UTC, Nicholas Wilson wrote:
> On Friday, 8 December 2017 at 10:46:20 UTC, John Colvin wrote:
>> On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson wrote:
>>> [...]
>>
>> How would such a thing interact with __traits(compiles, ...) and is-expressions?
>
> 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 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" and it would be the responsibility of the user. They could always reflect on the presence of the attribute if need be.
>
> From a point of consistency, probably however semantic constraints on things like LDC's magic attributes are done. I'm not sure how that is handled, but I suspect that __traits(compiles,...) does not take it into account. Johan?
>
> I will think more on it.
>
> Thanks.

You might want to wait until Dconf 2018 before you start implementing something.
As it happens I am working on a way which will make ctfe-only functions possible (though that's s side-effect rather then the goal)

On Fri, Dec 08, 2017 at 11:03:34AM +0000, 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 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 have to use if or a ternary operator or some other runtime conditional, though it's a common misunderstanding that __ctfe is used with static if, and people screw it up all the time. I don't know why it's a runtime thing rather than a compile time thing though. There's probably a good reason for it, but at first glance, it seems like a rather weird choice.
> > [...]
> > 
> > Sigh:
> > 
> > 	https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time
> > 
> > 
> > T
> 
> Woaaa... amazing job, Teoh!
> 
> It seems that no link in the wiki points to that, or I'm wrong? That valuable stuff should be more visible...
[...]

The reason nothing (official) points to it, is because it's still a draft that hasn't been polished, and some parts may not be 100% accurate.  Unfortunately, I haven't had the time to work on finishing it up.

But since it's a wiki, if you're up to it, contributions are welcome. :-)


T

-- 
Life is unfair. Ask too much from it, and it may decide you don't deserve what you have now either.

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 = <bool>;`?

https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time


T

-- 
I think the conspiracy theorists are out to get us...

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)
>> {
>> 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 magic, is actually a regular variable.
>
> While this looks not too inelegant for a user perspective, I dont know how to handle this from a compiler perspective: filtering by attribute is as easy as "does this function have a UDA ctfeonly? If so, don't code generate it. Generating errors at codegen time is also trivial: when generating a call check to see if the callee is @ctfeonly, if it is give an error message
>
> I don't know how to do that for a `static assert(__ctfe);`. That would require changes and semantic analysis in the front end which I am much less familiar with.
>

Oh, sorry, I forgot key detail! (parens)

int ctfeOnly()(int x) ...  (in my mind, it was a template function, which
means it would instantiate for the ctfe call separately to regular calls(?))

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 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.
>>
>
> That's exactly what happens if you put a declaration in a .h file, call the function, and don't link in the implementation. I don't see the difference.
>

Nicholas wants a *compile* error, not a link error.

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);
>> 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 static asserts are evaluated when the function is semantically analyzed, not when it is executed.
>

Sorry, in my mind, it was meant to be a template function...

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 targets).

 -David

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 result is only used at compile time (for a mixin) the compiler is free to not codegen that function.
>
> I can add this to LDC pretty easily, but does anyone else have a use for this (e.g. shrinking binary sizes for mixin heavy codebases) and would benefit having this as a standard thing?

This doesn't fulfill everything you're looking for, ie no compile-time error if tried to use at runtime, but isn't this existing idiom good enough?

https://github.com/dlang/phobos/blob/master/std/functional.d#L307