C3 0.8.3 Feature flags - C3 Programming Language Skip to content

Initializing search

Language Overview<br>C to C3<br>Language Fundamentals<br>Language Common<br>Generic Programming<br>Build Your Project<br>Language Rules<br>Misc Advanced<br>Implementation Details<br>FAQ

Get Involved

Thank You

Single Page Docs<br>📖 Standard Library<br>Blog

Possible keyword changes<br>Fetching MacOS<br>Windows Aarch64 support

Standard Library Updates<br>Fixes<br>Thank yous

C3 0.8.3 Feature flags<br>C3 0.8.3 is now available. The most notable change is the addition of the @feat attribute, which will be the new way to do top-level conditional compilation.<br>Language changes & improvements&para;<br>@feat&para;<br>This release adds the @feat attribute, which is replacing the older @if usage on non-generic top-level declarations. This attribute is essentially the same as @if($feature(...)) before 0.8.3, but top-level @if is now getting phased out except for use in generics.<br>The problem with @if&para;<br>Before @if we had $if on the top level, mirroring C's #if and #ifdef. However, this gave very little information for the compiler when someone tried to use a declaration guarded by $if. So @if was introduced to give more granular support and to make it easier for IDEs to figure out "go-to definition" style functionality.<br>Unfortunately, @if still had the problem of $if, which is that its argument could be any arbitrary compile time constant expression. But what happens if we use something like @if(Foo::methods.len == 3)? Well, if the compiler hasn't yet reached a stage where Foo is analysed, its analysis is now forced. Furthermore, even if Foo is analysed, methods might not be registered yet, giving subtly wrong answers. Because C3 runs in multiple passes, there is no canonical ordering of which thing to analyse first, so it was quite unpredictable. Even though refinements were constantly made to the ordering, the underlying flaw was unsolvable.<br>The insight&para;<br>Surveying the use of @if they roughly fell into one of three categories:<br>Conditionally include depending on compilation target, e.g. @if(env::WIN32)<br>Include "if no other implementation is found", e.g. @if(!$defined(String)).<br>Conditionally add functionality depending on generic type, e.g. @if($defined((Type){} + (Type){}))<br>Of these, the (3) didn't pose a problem in most cases, because in general it happened fairly late. In the case of (2), this was now mostly covered by the new behaviour of @weak (introduced in 0.7.11).<br>So what about @if(env::WIN32)? This was almost completely confined to the std::core::env module, which would define constants and derived constants based on compiler builtins, and all of those cases could actually be directly passed in by the compiler.<br>Introducing @feat&para;<br>As previously mentioned, @feat is essentially $if($feature(...)) but to make this work, the compiler now provides many feature flags built-in, such as WIN32, LINUX, BIG_ENDIAN etc. In general any use of env::CONSTANT has a @feat(CONSTANT) counterpart.<br>This solves the ordering problem because all these constants are known before declarations are registered, so any symbols with @feat can be filtered early. This is not only beneficial for the compiler – LSPs and editors can take advantage of this and accurately determine what's available at compile time.<br>In more detail, @feat may take multiple constants, in which case it is satisfied on any match:<br>fn void foo() @feat(WIN32, MACOS) // available on WIN32 and MACOS<br>{}

It's also possible to use | instead: fn void foo() @feat(WIN32 | MACOS) // alternative syntax<br>{}

! may be used to negate a feature: fn void foo() @feat(!WIN32) // available on anything other than WIN32<br>{}

Multiple @feat means all must be satisfied: fn void foo() @feat(MACOS) @feat(AARCH64) // only on Aarch64 MacOS<br>{}

It's possible to use & as an alternative: fn void foo() @feat(MACOS & AARCH64) // only on Aarch64 MacOS<br>{}

More complex expressions using | & and ! are allowed: fn void foo() @feat((MACOS & AARCH64) | !LIBC) // On Aarch64 MacOS or not with libc<br>{}

Together with this the $feature function has been renamed $feat ($feature is now deprecated and will be removed in 0.9.0).<br>Possible keyword changes&para;<br>0.7.0 introduced the family of "-def" keywords: constdef, typedef, faultdef and attrdef. After evaluating this for a little over a year, there has been some doubt whether these are really good enough. For this reason 0.8.3 introduces experimental aliases for each:<br>constdef -> constset, cenum<br>typedef -> distinct<br>faultdef -> faultconst, faultset, excuse<br>attrdef -> attrgroup, attrmacro<br>These are considered experimental, meaning that there is no stability guarantee. Versions 0.8.4 and onwards are free to remove these aliases.<br>Please take time to try them out and offer feedback on them.<br>Fetching MacOS&para;<br>Previously, automated fetching of the Windows SDK was added. This version adds SDK fetching for MacOS as well, allowing completely effortless cross-compilation to MacOS from any other platform.<br>Windows Aarch64...