Hello everyone!

I try build this code with betterC

import core.stdc.stdio;
import std.format : format;

extern(C) int main()
{
    mixin(format!`enum str = "%s\0";`("hello"));
    fprintf(stderr, "%s\n", str.ptr);
    return 0;
}

but compilation fails

/dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6278): Error: Cannot use try-catch statements with -betterC
/dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6308): Error: template instance `std.format.checkFormatException!("enum str = \"%s\\0\";", string)` error instantiating
onlineapp.d(6):        instantiated from here: format!("enum str = \"%s\\0\";", string)
/dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6311):        while evaluating: static assert(!e)
/dlang/dmd/linux/bin64/../../src/phobos/std/array.d(3204): Error: TypeInfo cannot be used with -betterC

Is this a bug?

https://run.dlang.io/is/TG1uhg

On Thursday, 25 July 2019 at 12:01:40 UTC, Oleg B wrote:
> Hello everyone!
>
> I try build this code with betterC
>
> import core.stdc.stdio;
> import std.format : format;
>
> extern(C) int main()
> {
>     mixin(format!`enum str = "%s\0";`("hello"));
>     fprintf(stderr, "%s\n", str.ptr);
>     return 0;
> }
>
> but compilation fails
>
> /dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6278): Error: Cannot use try-catch statements with -betterC
> /dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6308): Error: template instance `std.format.checkFormatException!("enum str = \"%s\\0\";", string)` error instantiating
> onlineapp.d(6):        instantiated from here: format!("enum str = \"%s\\0\";", string)
> /dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6311):
>  while evaluating: static assert(!e)
> /dlang/dmd/linux/bin64/../../src/phobos/std/array.d(3204): Error: TypeInfo cannot be used with -betterC
>
> Is this a bug?
>
> https://run.dlang.io/is/TG1uhg

If you read the documentation for betterC (https://dlang.org/spec/betterc.html#consequences) you'll see that there are features of the D language which are not supported. Therefore, libraries that use such features (e.g. std.format, std.array) are also not supported, and that is why you are encountering such errors.

There are some features of Phobos which can be used in betterC builds, but you're going to find that it's hit-and-miss.

Mike

On Thursday, 25 July 2019 at 12:20:04 UTC, Mike Franklin wrote:
>
> If you read the documentation for betterC (https://dlang.org/spec/betterc.html#consequences) you'll see that there are features of the D language which are not supported. Therefore, libraries that use such features (e.g. std.format, std.array) are also not supported, and that is why you are encountering such errors.
>
> There are some features of Phobos which can be used in betterC builds, but you're going to find that it's hit-and-miss.
>
> Mike

You don't understand my question and don't read code. I ask about compile time evaluation (`format` used inside `mixin` that means it must be computed at compile time). I know that I can't use many features with betterC at runtime.

On 26/07/2019 12:30 AM, Oleg B wrote:
> On Thursday, 25 July 2019 at 12:20:04 UTC, Mike Franklin wrote:
>>
>> If you read the documentation for betterC (https://dlang.org/spec/betterc.html#consequences) you'll see that there are features of the D language which are not supported. Therefore, libraries that use such features (e.g. std.format, std.array) are also not supported, and that is why you are encountering such errors.
>>
>> There are some features of Phobos which can be used in betterC builds, but you're going to find that it's hit-and-miss.
>>
>> Mike
> 
> You don't understand my question and don't read code. I ask about compile time evaluation (`format` used inside `mixin` that means it must be computed at compile time). I know that I can't use many features with betterC at runtime.

Those restrictions don't stop at runtime.

On Thursday, 25 July 2019 at 12:34:15 UTC, rikki cattermole wrote:
> Those restrictions don't stop at runtime.

It's vary sad.

What reason for such restrictions? It's fundamental idea or temporary implementation?

On 07/25/2019 05:46 AM, Oleg B wrote:
> On Thursday, 25 July 2019 at 12:34:15 UTC, rikki cattermole wrote:
>> Those restrictions don't stop at runtime.
> 
> It's vary sad.
> 
> What reason for such restrictions? It's fundamental idea or temporary implementation?

It looks like a bug to me.

Ali

On Thursday, 25 July 2019 at 12:46:48 UTC, Oleg B wrote:
> On Thursday, 25 July 2019 at 12:34:15 UTC, rikki cattermole wrote:
>> Those restrictions don't stop at runtime.
>
> It's vary sad.
>
> What reason for such restrictions? It's fundamental idea or temporary implementation?

Yes it is very sad.  It's an implementation thing.  I can guess as to a couple reasons why it doesn't work, but I think there's a few big ones that contribute to not being able to use certain features at compile-time without having it introduce things at runtime.

On Thursday, 25 July 2019 at 18:06:02 UTC, Jonathan Marler wrote:
> On Thursday, 25 July 2019 at 12:46:48 UTC, Oleg B wrote:
>> On Thursday, 25 July 2019 at 12:34:15 UTC, rikki cattermole wrote:
>>> Those restrictions don't stop at runtime.
>>
>> It's vary sad.
>>
>> What reason for such restrictions? It's fundamental idea or temporary implementation?
>
> Yes it is very sad.  It's an implementation thing.  I can guess as to a couple reasons why it doesn't work, but I think there's a few big ones that contribute to not being able to use certain features at compile-time without having it introduce things at runtime.

Anything you do at compile-time should never produce anything at runtime UNLESS it's a field created or something created using mixin.

D's betterC is pretty useless if you can't use D to its fullest at compile-time regardless of whether you're compiling with betterC or not.

It takes the one thing away from D that it does better than other languages, which is CTFE and metaprogramming.

On Thursday, July 25, 2019 8:20:03 AM MDT Ali Çehreli via Digitalmars-d- learn wrote:
> On 07/25/2019 05:46 AM, Oleg B wrote:
> > On Thursday, 25 July 2019 at 12:34:15 UTC, rikki cattermole wrote:
> >> Those restrictions don't stop at runtime.
> >
> > It's vary sad.
> >
> > What reason for such restrictions? It's fundamental idea or temporary implementation?
>
> It looks like a bug to me.

There's probably at least one bug report on it, but as I understand it, it's not a bug in the sense that the implementation is currently expected to handle such a case. It's an area where betterC should be improved upon, but it would be an enhancement, not a bug fix.

- Jonathan M Davis

On Thursday, 25 July 2019 at 18:37:49 UTC, Jonathan M Davis wrote:

> There's probably at least one bug report on it, but as I understand it, it's not a bug in the sense that the implementation is currently expected to handle such a case. It's an area where betterC should be improved upon, but it would be an enhancement, not a bug fix.

Yes.  The point is that libraries have to be written with betterC and compile-time evaluation in mind.  If they aren't the code is likely not going to work in those use cases.  Much of the code in Phobos was written long before betterC was introduced.

There are probably changes that could be made to Phobos so the OP could get a build, but that requires someone with enough interest in the issue to volunteer their time and talent to improve the implementation for betterC and compile-time use cases.

We have a GSoC student making changes the druntime to help with this matter and I have been picking away at it too.  It will take time and could use more contributors.

Mike