3 ms·

> Evaluating Constant Expressions The examples are quite simple in the article but I believe more complex cases would significantly degrade the compiler speed

by kreco 2y ago

> Evaluating Constant Expressions The examples are quite simple in the article but I believe more complex cases would significantly degrade the compiler speed (and probably the memory footprint as well) and would require a VM to leverage this. Which is probably assumed "too complex" to go into the standard. I'm not saying it's impossible, but I kind of understand why this would not go into any kind of standard. > Importing Declarations I wish C++ (or even C) would have gone into this direction instead the weird mess of what is defined for C++20. Additionally you might import module into some symbol, like: #import "string.c" as str and every non-static symbols from the file can be accessed from like: str.trim(" Hello World "); > __import dex; This is totally tangential but I don't like when file paths are not explicit. In this specific case I don't know if I'm importing dex.d or dex.c.

WalterBright 2y ago
> I kind of understand why this would not go into any kind of standard. Other popular languages can do it. That aside, it is an immensely popular and useful feature in D. And yes, as one would expect, the more it is used, there's compile time speed and memory consumption required. As for a VM, the constant folder is already a VM. This just extends it to be able to handle function calls. C has simple semantics, so it's not that bad. > Additionally Great minds think alike! Your suggestions are just what D imports do. https://dlang.org/spec/module.html#import-declaration https://dlang.org/spec/module.html#import-declaration > In this specific case I don't know if I'm importing dex.d or dex.c This issue does come up. The answer is setting up your import path. It's analogous to the C compiler include path.
loeg 2y ago
> The examples are quite simple in the article but I believe more complex cases would significantly degrade the compiler speed (and probably the memory footprint as well) and would require a VM to leverage this. > Which is probably assumed "too complex" to go into the standard. I'm not saying it's impossible, but I kind of understand why this would not go into any kind of standard. I mean, it's basically 1:1 with the constexpr feature in C++. Almost every C compiler is already a C++ compiler, supporting constexpr functions and evaluation in C can't be that bad, can it?
thayne 2y ago
> I believe more complex cases would significantly degrade the compiler speed (and probably the memory footprint as well) and would require a VM to leverage this. I'm pretty sure most production grade c compilers already do some level of compiler time evaluation for optimization. And C already has constant expressions. I think a bigger hurdle would be that the compiler needs access to the source code of the function, so it would probably be restricted to functions in the same translation unit. And then there is the possibly even bigger people problem of getting a committee with representives from multiple compilers to agree on the semantics of such constant evaluation.

by kreco 2y ago

WalterBright 2y ago

> I kind of understand why this would not go into any kind of standard. Other popular languages can do it. That aside, it is an immensely popular and useful feature in D. And yes, as one would expect, the more it is used, there's compile time speed and memory consumption required. As for a VM, the constant folder is already a VM. This just extends it to be able to handle function calls. C has simple semantics, so it's not that bad. > Additionally Great minds think alike! Your suggestions are just what D imports do. https://dlang.org/spec/module.html#import-declaration https://dlang.org/spec/module.html#import-declaration > In this specific case I don't know if I'm importing dex.d or dex.c This issue does come up. The answer is setting up your import path. It's analogous to the C compiler include path.

loeg 2y ago

> The examples are quite simple in the article but I believe more complex cases would significantly degrade the compiler speed (and probably the memory footprint as well) and would require a VM to leverage this. > Which is probably assumed "too complex" to go into the standard. I'm not saying it's impossible, but I kind of understand why this would not go into any kind of standard. I mean, it's basically 1:1 with the constexpr feature in C++. Almost every C compiler is already a C++ compiler, supporting constexpr functions and evaluation in C can't be that bad, can it?

thayne 2y ago

> I believe more complex cases would significantly degrade the compiler speed (and probably the memory footprint as well) and would require a VM to leverage this. I'm pretty sure most production grade c compilers already do some level of compiler time evaluation for optimization. And C already has constant expressions. I think a bigger hurdle would be that the compiler needs access to the source code of the function, so it would probably be restricted to functions in the same translation unit. And then there is the possibly even bigger people problem of getting a committee with representives from multiple compilers to agree on the semantics of such constant evaluation.