digitalmars.D - Proof of concept: automatically import C header files
- Jacob Carlborg (17/17) Jul 16 2013 Made a proof of concept to automatically parse, translate and import C
- Robert (2/5) Jul 16 2013 awesome! :-)
- Dicebot (7/10) Jul 16 2013 While this a relatively common request, I don't think such stuff
- Timothee Cour (26/35) Jul 16 2013 I agree that this stuff doesn't belong to compiler, however Makefiles su...
- Walter Bright (3/4) Jul 16 2013 While semantically a great idea, technically I don't think CTFE is up to...
- Timothee Cour (4/10) Jul 16 2013 it would trivially, with CTFE exec.
- deadalnix (3/18) Jul 16 2013 Just because a bad solution is faster to implement doesn't make
- Timothee Cour (2/20) Jul 16 2013 Being lazy is good. Less bugs to fix, etc.
- deadalnix (2/7) Jul 16 2013 This is the right path. We don't need the full front end, do we ?
- Timothee Cour (6/17) Jul 16 2013 what's a non-full C front end? If it's not a real C front end it's gonna
- deadalnix (6/14) Jul 16 2013 Macro are processed before parsing? No need for a full C frontend
- Timothee Cour (7/21) Jul 17 2013 you'd still need to parse C files recursively (textual inclusion...),
- deadalnix (4/15) Jul 17 2013 I'm talking about semantic analysis, you answer with parsing, I'm
- Walter Bright (5/12) Jul 17 2013 Yeah, you do need the full front end. It's pretty amazing how the simple...
- Jacob Carlborg (8/13) Jul 17 2013 When you do have a complete front end you can choose how to handle the
- Paulo Pinto (4/20) Jul 17 2013 Thus we are back to the compiler as library discussion.
- Jacob Carlborg (5/6) Jul 17 2013 Yes, but for the C family of languages we already have a compiler as
- Paulo Pinto (11/15) Jul 18 2013 Agreed.
- deadalnix (4/20) Jul 17 2013 My understanding is that we only want to convert declaration to
- Walter Bright (10/12) Jul 17 2013 One example:
- H. S. Teoh (11/29) Jul 17 2013 I've seen C code where the "header" file has function bodies in them.
- Walter Bright (7/13) Jul 17 2013 Building a correct C front end is a known technology, doing a half-baked...
- H. S. Teoh (35/53) Jul 17 2013 IOW either you don't do it at all, or you have to go all the way and
- Jacob Carlborg (6/37) Jul 17 2013 You will just end up needing to build a full C preprocessor. Just use an...
- Jacob Carlborg (18/22) Jul 17 2013 And things like:
- deadalnix (2/17) Jul 17 2013 This do not require semantic analysis.
- Walter Bright (3/21) Jul 17 2013 Semantic analysis for C is trivial. The real problems are the phases of
- Walter Bright (13/23) Jul 17 2013 Yes, but the front end itself must be complete. Otherwise,
- Jacob Carlborg (9/22) Jul 17 2013 Yes, I agree with all the above. That's why I'm using libclang. What I'm...
- Jacob Carlborg (6/7) Jul 17 2013 Oh, yes we do. You will always run into corner cases your tool cannot
- Dicebot (4/8) Jul 16 2013 ..but not here. Integrated solutions suck even harder than
- Jacob Carlborg (7/10) Jul 17 2013 I started to think a bit about this. One might need to specify various
- angel (2/2) Jul 16 2013 Possibly instead of 'include' would be better use 'include_C' as
- Jacob Carlborg (5/7) Jul 17 2013 Or there could be an optional argument indicating the language.
- Chad Joan (9/25) Jul 17 2013 This sounds pretty cool, and the suggestion from Timothee also
Made a proof of concept to automatically parse, translate and import C header files in D using DStep. DMD is linked against DStep and does not start new process to make the translation. I added a new pragma, include, that handles everything. Use like this: // foo.h void foo (); // main.d module main; pragma(include, "foo.h"); void main () { foo(); } DMD: https://github.com/jacob-carlborg/dmd/tree/dstep DStep: https://github.com/jacob-carlborg/dstep/tree/c_api -- /Jacob Carlborg
Jul 16 2013
On Tuesday, 16 July 2013 at 14:15:55 UTC, Jacob Carlborg wrote:Made a proof of concept to automatically parse, translate and import C header files in D using DStep. DMD is linked against DStep and does not start new process to make the translation.awesome! :-)
Jul 16 2013
On Tuesday, 16 July 2013 at 14:15:55 UTC, Jacob Carlborg wrote:Made a proof of concept to automatically parse, translate and import C header files in D using DStep. DMD is linked against DStep and does not start new process to make the translation.While this a relatively common request, I don't think such stuff belongs to compiler. It creates extra mandatory dependencies while providing little advantage over doing this as part of a build system. So far I am perfectly satisfied with invoking dstep from a Makefile.
Jul 16 2013
On Tue, Jul 16, 2013 at 8:05 AM, Dicebot <public dicebot.lv> wrote:On Tuesday, 16 July 2013 at 14:15:55 UTC, Jacob Carlborg wrote:I agree that this stuff doesn't belong to compiler, however Makefiles suck (not even portable) and build systems should be avoided whenever a more integrated solution exist. So how about a library solution instead, which doesn't require compiler change: ---- import parse_c_header_importer; mixin(parse_c_header(import("foo.h"))); void main () { foo();} ---- There are several options: A) mixin(parse_c_header(import("foo.h"))); => defines D symbols for everything in foo.h (excluding things included by it) B) mixin(parse_c_header(import("foo.h"),recursive)); => same, but recursively (probably not very useful, but could be useful if we instead used .i swig interface files. C) The least wasteful: void foo(); int bar(); mixin(parse_c_header(import("foo.h"),foo,bar)); => only defines symbols provided (I've proposed this syntax in an earlier thread)Made a proof of concept to automatically parse, translate and import C header files in D using DStep. DMD is linked against DStep and does not start new process to make the translation.While this a relatively common request, I don't think such stuff belongs to compiler. It creates extra mandatory dependencies while providing little advantage over doing this as part of a build system. So far I am perfectly satisfied with invoking dstep from a Makefile.
Jul 16 2013
On 7/16/2013 8:49 PM, Timothee Cour wrote:So how about a library solution instead, which doesn't require compiler change:While semantically a great idea, technically I don't think CTFE is up to implementing a C front end yet.
Jul 16 2013
On Tue, Jul 16, 2013 at 9:14 PM, Walter Bright <newshound2 digitalmars.com>wrote:On 7/16/2013 8:49 PM, Timothee Cour wrote:it would trivially, with CTFE exec. Yet another enabling use case.So how about a library solution instead, which doesn't require compiler change:While semantically a great idea, technically I don't think CTFE is up to implementing a C front end yet.
Jul 16 2013
On Wednesday, 17 July 2013 at 04:32:12 UTC, Timothee Cour wrote:On Tue, Jul 16, 2013 at 9:14 PM, Walter Bright <newshound2 digitalmars.com>wrote:Just because a bad solution is faster to implement doesn't make it good.On 7/16/2013 8:49 PM, Timothee Cour wrote:it would trivially, with CTFE exec. Yet another enabling use case.So how about a library solution instead, which doesn't require compiler change:While semantically a great idea, technically I don't think CTFE is up to implementing a C front end yet.
Jul 16 2013
On Tue, Jul 16, 2013 at 10:02 PM, deadalnix <deadalnix gmail.com> wrote:On Wednesday, 17 July 2013 at 04:32:12 UTC, Timothee Cour wrote:Being lazy is good. Less bugs to fix, etc.On Tue, Jul 16, 2013 at 9:14 PM, Walter Bright <newshound2 digitalmars.com>**wrote: On 7/16/2013 8:49 PM, Timothee Cour wrote:Just because a bad solution is faster to implement doesn't make it good.So how about a library solution instead, which doesn't require compilerit would trivially, with CTFE exec. Yet another enabling use case.change:While semantically a great idea, technically I don't think CTFE is up to implementing a C front end yet.
Jul 16 2013
On Wednesday, 17 July 2013 at 04:14:56 UTC, Walter Bright wrote:On 7/16/2013 8:49 PM, Timothee Cour wrote:This is the right path. We don't need the full front end, do we ?So how about a library solution instead, which doesn't require compiler change:While semantically a great idea, technically I don't think CTFE is up to implementing a C front end yet.
Jul 16 2013
On Tue, Jul 16, 2013 at 10:04 PM, deadalnix <deadalnix gmail.com> wrote:On Wednesday, 17 July 2013 at 04:14:56 UTC, Walter Bright wrote:what's a non-full C front end? If it's not a real C front end it's gonna break with certain macros etc. Not good. I see no point in re-implementing a C front end when we can simply use an existing one to do the job (eg clang). This would also allow to parse C++ just as well.On 7/16/2013 8:49 PM, Timothee Cour wrote:This is the right path. We don't need the full front end, do we ?So how about a library solution instead, which doesn't require compiler change:While semantically a great idea, technically I don't think CTFE is up to implementing a C front end yet.
Jul 16 2013
On Wednesday, 17 July 2013 at 05:12:00 UTC, Timothee Cour wrote:what's a non-full C front end? If it's not a real C front end it's gonna break with certain macros etc. Not good.Macro are processed before parsing? No need for a full C frontend to handle macros.I see no point in re-implementing a C front end when we can simply use an existing one to do the job (eg clang). This would also allow to parse C++ just as well.When you only need a very limited part of the fronted, it make sense. Here we don't need to parse function body for instance, and we can skip most of semantic analysis (if not all ?).
Jul 16 2013
On Tue, Jul 16, 2013 at 11:01 PM, deadalnix <deadalnix gmail.com> wrote:On Wednesday, 17 July 2013 at 05:12:00 UTC, Timothee Cour wrote:you'd still need to parse C files recursively (textual inclusion...), handle different C function calling conventions, different C standards, you'd need a way to forward to dmd different C compiler options (include paths to standard / custom libraries), and eventually people will want to parse C++ as well anyways. That can be a lot of work. Whereas using existing tools takes much less effort and is less error prone.what's a non-full C front end? If it's not a real C front end it's gonna break with certain macros etc. Not good.Macro are processed before parsing? No need for a full C frontend to handle macros. I see no point in re-implementing a C front end when we can simply use anexisting one to do the job (eg clang). This would also allow to parse C++ just as well.When you only need a very limited part of the fronted, it make sense. Here we don't need to parse function body for instance, and we can skip most of semantic analysis (if not all ?).
Jul 17 2013
On Wednesday, 17 July 2013 at 07:17:07 UTC, Timothee Cour wrote:you'd still need to parse C files recursively (textual inclusion...), handle different C function calling conventions, different C standards, you'd need a way to forward to dmd different C compiler options (include paths to standard / custom libraries), and eventually people will want to parse C++ as well anyways. That can be a lot of work. Whereas using existing tools takes much less effort and is less error prone.I'm talking about semantic analysis, you answer with parsing, I'm not sure this is going to lead anywhere. Do you understand that a parser is actually quite a small part of a frontend ?
Jul 17 2013
On 7/16/2013 10:04 PM, deadalnix wrote:On Wednesday, 17 July 2013 at 04:14:56 UTC, Walter Bright wrote:Yeah, you do need the full front end. It's pretty amazing how the simplest of .h files seem determined to exercise every last, dark corner of the language. If the converter doesn't accept the full language, you're just going to get a dump truck unloading on it.On 7/16/2013 8:49 PM, Timothee Cour wrote:This is the right path. We don't need the full front end, do we ?So how about a library solution instead, which doesn't require compiler change:While semantically a great idea, technically I don't think CTFE is up to implementing a C front end yet.
Jul 17 2013
On 2013-07-17 10:14, Walter Bright wrote:Yeah, you do need the full front end. It's pretty amazing how the simplest of .h files seem determined to exercise every last, dark corner of the language. If the converter doesn't accept the full language, you're just going to get a dump truck unloading on it.When you do have a complete front end you can choose how to handle the language constructs the tool cannot (yet) translate. I.e. just skip it, insert a comment or similar. If you don't have a full front end and encounters something that you cannot translate, you will most likely have weird behaviors. -- /Jacob Carlborg
Jul 17 2013
On Wednesday, 17 July 2013 at 09:27:53 UTC, Jacob Carlborg wrote:On 2013-07-17 10:14, Walter Bright wrote:Thus we are back to the compiler as library discussion. -- PauloYeah, you do need the full front end. It's pretty amazing how the simplest of .h files seem determined to exercise every last, dark corner of the language. If the converter doesn't accept the full language, you're just going to get a dump truck unloading on it.When you do have a complete front end you can choose how to handle the language constructs the tool cannot (yet) translate. I.e. just skip it, insert a comment or similar. If you don't have a full front end and encounters something that you cannot translate, you will most likely have weird behaviors.
Jul 17 2013
On 2013-07-17 13:24, Paulo Pinto wrote:Thus we are back to the compiler as library discussion.Yes, but for the C family of languages we already have a compiler as library, that is Clang. -- /Jacob Carlborg
Jul 17 2013
On Wednesday, 17 July 2013 at 15:34:54 UTC, Jacob Carlborg wrote:On 2013-07-17 13:24, Paulo Pinto wrote:Agreed. I also confess that my anti-C bias got a bit softened with clang. It does not sort out all C and C++ issues in regard with safety, but it helps bringing to C a Pascal like safety when integrated with proper tooling. Unfortunately when using C and C++, not all compilers are like clang and it is not always easy to convince people to add extra tooling (lint and friends). -- PauloThus we are back to the compiler as library discussion.Yes, but for the C family of languages we already have a compiler as library, that is Clang.
Jul 18 2013
On Wednesday, 17 July 2013 at 09:27:53 UTC, Jacob Carlborg wrote:On 2013-07-17 10:14, Walter Bright wrote:My understanding is that we only want to convert declaration to D. Can you give me an example of such corner case that would require the full frontend ?Yeah, you do need the full front end. It's pretty amazing how the simplest of .h files seem determined to exercise every last, dark corner of the language. If the converter doesn't accept the full language, you're just going to get a dump truck unloading on it.When you do have a complete front end you can choose how to handle the language constructs the tool cannot (yet) translate. I.e. just skip it, insert a comment or similar. If you don't have a full front end and encounters something that you cannot translate, you will most likely have weird behaviors.
Jul 17 2013
On 7/17/2013 9:48 AM, deadalnix wrote:My understanding is that we only want to convert declaration to D. Can you give me an example of such corner case that would require the full frontend ?One example: -------------------------------- //**************************Header**********************\\ int x; -------------------------------- Yes, this POS is real C code I got a bug report on. Note the trailing \\. Is that one line splice or two? You have to get the hairy details right. I've seen similar nonsense with trigraphs. I've seen metaprogramming tricks with token pasting. You can't dismiss this stuff.
Jul 17 2013
On Wed, Jul 17, 2013 at 12:46:54PM -0700, Walter Bright wrote:On 7/17/2013 9:48 AM, deadalnix wrote:I've seen C code where the "header" file has function bodies in them. Though about trigraphs... I've to admit I've never actually seen *real* C code that uses trigraphs, but yeah, needing to account for them can significantly complicate your code. But as for preprocessor-specific stuff, couldn't we just pipe it through a standalone C preprocessor and be done with it? It can't be *that* hard, right? T -- Bare foot: (n.) A device for locating thumb tacks on the floor.My understanding is that we only want to convert declaration to D. Can you give me an example of such corner case that would require the full frontend ?One example: -------------------------------- //**************************Header**********************\\ int x; -------------------------------- Yes, this POS is real C code I got a bug report on. Note the trailing \\. Is that one line splice or two? You have to get the hairy details right. I've seen similar nonsense with trigraphs. I've seen metaprogramming tricks with token pasting. You can't dismiss this stuff.
Jul 17 2013
On 7/17/2013 3:20 PM, H. S. Teoh wrote:Though about trigraphs... I've to admit I've never actually seen *real* C code that uses trigraphs, but yeah, needing to account for them can significantly complicate your code.Building a correct C front end is a known technology, doing a half-baked job isn't going to impress people.But as for preprocessor-specific stuff, couldn't we just pipe it through a standalone C preprocessor and be done with it? It can't be *that* hard, right?You could, but then you are left with failing to recognize: #define FOO 3 and converting it to: enum FOO = 3;
Jul 17 2013
On Wed, Jul 17, 2013 at 03:36:15PM -0700, Walter Bright wrote:On 7/17/2013 3:20 PM, H. S. Teoh wrote:IOW either you don't do it at all, or you have to go all the way and implement a fully-functional C frontend? If so, libclang is starting to sound rather attractive...Though about trigraphs... I've to admit I've never actually seen *real* C code that uses trigraphs, but yeah, needing to account for them can significantly complicate your code.Building a correct C front end is a known technology, doing a half-baked job isn't going to impress people.Hmm. We *could* pre-preprocess the code to do this conversion first to pick out these #define's, then suppress the #define's we understand from the input to the C preprocessor. Something like this: bool isSimpleValue(string s) { // basically, return true if s is something compilable // when put on the right side of "enum x = ...". } auto pipe = spawnCPreprocessor(); string[string] manifestConstants; foreach (line; inputFile.byLine()) { if (auto m=match(line, `^\s*#define\s+(\w+)\s+(.*?)\s+`)) { if (isSimpleValue(m.captures[2])) { manifestConstants[m.captures[1]] = m.captures[2]; // Suppress enums that we picked out continue; } // whatever we don't understand, hand over to // the C preprocessor } pipe.writeln(line); } Basically, whatever #define's we can understand, we handle, and anything else we let the C preprocessor deal with. By suppressing the #define's we've picked out, we force the C preprocessor to leave any reference to them as unexpanded identifiers, so that later on we can just generate the enums and the resulting code will match up correctly. T -- Prosperity breeds contempt, and poverty breeds consent. -- Suck.comBut as for preprocessor-specific stuff, couldn't we just pipe it through a standalone C preprocessor and be done with it? It can't be *that* hard, right?You could, but then you are left with failing to recognize: #define FOO 3 and converting it to: enum FOO = 3;
Jul 17 2013
On 2013-07-18 00:59, H. S. Teoh wrote:IOW either you don't do it at all, or you have to go all the way and implement a fully-functional C frontend? If so, libclang is starting to sound rather attractive...That's what I'm tellingHmm. We *could* pre-preprocess the code to do this conversion first to pick out these #define's, then suppress the #define's we understand from the input to the C preprocessor. Something like this: bool isSimpleValue(string s) { // basically, return true if s is something compilable // when put on the right side of "enum x = ...". } auto pipe = spawnCPreprocessor(); string[string] manifestConstants; foreach (line; inputFile.byLine()) { if (auto m=match(line, `^\s*#define\s+(\w+)\s+(.*?)\s+`)) { if (isSimpleValue(m.captures[2])) { manifestConstants[m.captures[1]] = m.captures[2]; // Suppress enums that we picked out continue; } // whatever we don't understand, hand over to // the C preprocessor } pipe.writeln(line); } Basically, whatever #define's we can understand, we handle, and anything else we let the C preprocessor deal with. By suppressing the #define's we've picked out, we force the C preprocessor to leave any reference to them as unexpanded identifiers, so that later on we can just generate the enums and the resulting code will match up correctly.You will just end up needing to build a full C preprocessor. Just use an existing one, that is libclang. -- /Jacob Carlborg
Jul 17 2013
On 2013-07-18 00:36, Walter Bright wrote:You could, but then you are left with failing to recognize: #define FOO 3 and converting it to: enum FOO = 3;And things like: #if linux short a; #elif _WIN32 || _WIN64 int a; #endif Should preferably be converted to: version (linux) short a; else version (Windows) int a; Other example: #define foo(a, b) a + b Should be converted to: auto foo (A, B) (A a, B b) { return a + b; } -- /Jacob Carlborg
Jul 17 2013
On Wednesday, 17 July 2013 at 19:46:54 UTC, Walter Bright wrote:On 7/17/2013 9:48 AM, deadalnix wrote:This do not require semantic analysis.My understanding is that we only want to convert declaration to D. Can you give me an example of such corner case that would require the full frontend ?One example: -------------------------------- //**************************Header**********************\\ int x; -------------------------------- Yes, this POS is real C code I got a bug report on. Note the trailing \\. Is that one line splice or two? You have to get the hairy details right. I've seen similar nonsense with trigraphs. I've seen metaprogramming tricks with token pasting. You can't dismiss this stuff.
Jul 17 2013
On 7/17/2013 5:31 PM, deadalnix wrote:On Wednesday, 17 July 2013 at 19:46:54 UTC, Walter Bright wrote:Semantic analysis for C is trivial. The real problems are the phases of translation and the preprocessor.On 7/17/2013 9:48 AM, deadalnix wrote:This do not require semantic analysis.My understanding is that we only want to convert declaration to D. Can you give me an example of such corner case that would require the full frontend ?One example: -------------------------------- //**************************Header**********************\\ int x; -------------------------------- Yes, this POS is real C code I got a bug report on. Note the trailing \\. Is that one line splice or two? You have to get the hairy details right. I've seen similar nonsense with trigraphs. I've seen metaprogramming tricks with token pasting. You can't dismiss this stuff.
Jul 17 2013
On 7/17/2013 2:27 AM, Jacob Carlborg wrote:On 2013-07-17 10:14, Walter Bright wrote:Yes, but the front end itself must be complete. Otherwise, it's not really practical when you're dealing with things like the preprocessor - because a non-compliant front end won't even know it has gone off the rails. There are other issues when dealing with C .h files: 1. there may be various #define's necessary to compile it that would normally be supplied on the command line to the C compiler 2. there are various behavior switches (see the PR for DMD that wants to set the signed'ness of char types) 3. rather few .h files seem to be standard compliant C. They always rely on various compiler extensions These problems are not insurmountable, they just are non-trivial and need to be handled for a successful .h file importer.Yeah, you do need the full front end. It's pretty amazing how the simplest of .h files seem determined to exercise every last, dark corner of the language. If the converter doesn't accept the full language, you're just going to get a dump truck unloading on it.When you do have a complete front end you can choose how to handle the language constructs the tool cannot (yet) translate. I.e. just skip it, insert a comment or similar.
Jul 17 2013
On 2013-07-17 21:40, Walter Bright wrote:Yes, but the front end itself must be complete. Otherwise, it's not really practical when you're dealing with things like the preprocessor - because a non-compliant front end won't even know it has gone off the rails. There are other issues when dealing with C .h files: 1. there may be various #define's necessary to compile it that would normally be supplied on the command line to the C compiler 2. there are various behavior switches (see the PR for DMD that wants to set the signed'ness of char types) 3. rather few .h files seem to be standard compliant C. They always rely on various compiler extensions These problems are not insurmountable, they just are non-trivial and need to be handled for a successful .h file importer.Yes, I agree with all the above. That's why I'm using libclang. What I'm saying is that when I use a library like libclang I can choose quite freely what to convert and not convert. Example, DStep doesn't handle the preprocessor at all. But since libclang does, it can parse any header file anyway. What happens is just that the preprocessor declarations won't be translated and not end up in the translated file. -- /Jacob Carlborg
Jul 17 2013
On 2013-07-17 07:04, deadalnix wrote:This is the right path. We don't need the full front end, do we ?Oh, yes we do. You will always run into corner cases your tool cannot handle until you have a complete front end. I tried that first, before I used libclang. -- /Jacob Carlborg
Jul 17 2013
On Wednesday, 17 July 2013 at 03:49:32 UTC, Timothee Cour wrote:I agree that this stuff doesn't belong to compiler, however Makefiles suckHere I may agree (for a different reasons probably)and build systems should be avoided whenever a more integrated solution exist...but not here. Integrated solutions suck even harder than Makefiles.
Jul 16 2013
On 2013-07-16 17:05, Dicebot wrote:While this a relatively common request, I don't think such stuff belongs to compiler. It creates extra mandatory dependencies while providing little advantage over doing this as part of a build system.I started to think a bit about this. One might need to specify various options to translate the header file. Options like include paths and similar. That might be quite problematic to do in a pragam, or via DMD command line options. -- /Jacob Carlborg
Jul 17 2013
Possibly instead of 'include' would be better use 'include_C' as opposed to C++ or any other language.
Jul 16 2013
On 2013-07-17 08:29, angel wrote:Possibly instead of 'include' would be better use 'include_C' as opposed to C++ or any other language.Or there could be an optional argument indicating the language. pragma(include, "foo.h", "C"); -- /Jacob Carlborg
Jul 17 2013
On Tuesday, 16 July 2013 at 14:15:55 UTC, Jacob Carlborg wrote:Made a proof of concept to automatically parse, translate and import C header files in D using DStep. DMD is linked against DStep and does not start new process to make the translation. I added a new pragma, include, that handles everything. Use like this: // foo.h void foo (); // main.d module main; pragma(include, "foo.h"); void main () { foo(); } DMD: https://github.com/jacob-carlborg/dmd/tree/dstep DStep: https://github.com/jacob-carlborg/dstep/tree/c_apiThis sounds pretty cool, and the suggestion from Timothee also makes a lot of sense. Is there any way we can rig this to behave as if it were a CTFE invocation? It could be treated like an intrinsic up to the point where we have powerful-enough CTFE to replace it. I'm still not sure if Walter would be OK with this, but I figure I'd mention it, since it could give us something really nice without having to wait for CTFE to get good.
Jul 17 2013