www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Is betterC affect to compile time?

reply Oleg B <code.viator gmail.com> writes:
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
Jul 25 2019
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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
Jul 25 2019
parent reply Oleg B <code.viator gmail.com> writes:
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.
Jul 25 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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.
Jul 25 2019
parent reply Oleg B <code.viator gmail.com> writes:
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?
Jul 25 2019
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Jul 25 2019
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Jul 25 2019
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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
Jul 25 2019
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, July 25, 2019 6:13:38 PM MDT Mike Franklin via Digitalmars-d-
learn wrote:
 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.
I honestly don't see why how the library works should matter for CTFE so long as it's CTFE-able. format creates a string, and mixin then mixes in that string as code. None of that should have any effect on the generated code or what happens at runtime beyond the code that's mixed in. Sure, whether a library can be used with betterC at runtime depends on how the library was implemented, but runtime is a completely different beast from compile time. IMHO, the fact that you can't use format to create a compile-time construct with betterC is purely a problem with dmd's current implementation. - Jonathan M Davis
Jul 26 2019
prev sibling parent Max Haughton <maxhaton gmail.com> writes:
On Thursday, 25 July 2019 at 14:20:03 UTC, Ali Çehreli 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. Ali
If the spec is to be believed then it is. I filed a bugzilla, https://issues.dlang.org/show_bug.cgi?id=20086
Jul 26 2019
prev sibling next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
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.
Jul 25 2019
parent bauss <jj_1337 live.dk> writes:
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.
Jul 25 2019
prev sibling parent Kagamin <spam here.lot> writes:
On Thursday, 25 July 2019 at 12:46:48 UTC, Oleg B wrote:
 What reason for such restrictions? It's fundamental idea or 
 temporary implementation?
I think it's a dmd limitation. Currently it has a bug that it can still generate code for ctfe templated functions, and they will fail to link if they use runtime. So yeah, currently betterC really means betterC all the way down. The alternative is to compile without -betterC switch and just use a minimal runtime if you use runtime features, then you have full language in ctfe.
Jul 26 2019