On 7 December 2017 at 17:20, Manu <turkey...@gmail.com> wrote:
> On 7 December 2017 at 13:35, Walter Bright via Digitalmars-d <
> digitalmars-d@puremagic.com> wrote:
>
>> 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
>> generated.
>>
>> In any case, in C/C++/D if you call functions in .h files (or imports)
>> that are not linked in, you'll get a linker error.
>>
>
> 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.
> 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.
>
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?
