151–160 of 270 posts
I’m seeing a lot of this in the docs:
“However, just like for const the compiler might not detect whether the annotation is correct or not! This program might compile, but will behave strangely:”
" the C-like for programmers who like C." Sounds intriguing. But then, the first thing I noticed in their example is a double-colon scope operator. I understand that it's part of the culture (and Rust, C#, and many other languages), but I find the syntax itself ugly. I dunno. Maybe I have the visual equivalent of misophonia, in addition to the auditory version, but :: and x I like C. But I abhor C++ with a passion, p…
Two reasons, the second being the important: (1) If I read "io.print", is this "the print function in the module io" or "the print method for the variable io". There tends to be an overlap in naming here so that's a downside (2) parsing and semantic checking is much easier if the namespace is clear from the grammar. In particular, C3's "path shortening", where you're allowed to write `file::open("foo.txt")` rather th…
I don't see the issue. Just look up the id ? Moreover, if modules are seen as objects, the meaning is quite the same.
> checking is much easier if the namespace is clear from the grammar.
Again (this time by the checker) just look up the symbol table ?
Earlier quoted context omitted.
Contracts are a way to express invariants, "This shall always be true". There are three main things you could do with these invariants, the exact details of how to do them, and whether people should be allowed to specify which of these things to do, and if so whether they can pick only for a whole program, per-file, per-function, or whatever, is separate. 1. Ignore the invariants. You wrote them down, a human can rea…
In other words, in production mode it makes your code faster and less safe; in debug mode it makes your code slower and more safe. That's a valid trade-off to make. But it's unexpected for a language that bills itself as "The Ergonomic, Safe and Familiar Evolution of C". Those pre/post-conditions are written by humans (or an LLM). Occasionally they're going to be wrong, and occasionally they're not going to be caught…
No, I think this is a very ergonomic feature. It fits nicely because it allows better compilers to use the constraints to optimize more confidently than equivalently-smart C compilers.
I think the switch statement design is a foot gun: defaults to fall-through when empty and break when there is a body. https://c3-lang.org/language-overview/examples/#enum-and-swi...
This feels very natural though, in a "principle of least surprise" kinda way. This is what you'd expect a properly designed switch statement to do.
Earlier quoted context omitted.
This feels very natural though, in a "principle of least surprise" kinda way. This is what you'd expect a properly designed switch statement to do.
Least surprise to who? Are there any other mainstream languages that behave this way? I think consistency is the best correlate of least surprise, so having case statements that sometimes fall though, sometimes not, seems awful.
Dumb question about contracts: I was reading the docs ( https://c3-lang.org/language-common/contracts/ ) and this jumped out "Contracts are optional pre- and post-condition checks that the compiler may use for static analysis, runtime checks and optimization. Note that conforming C3 compilers are not obliged to use pre- and post-conditions at all. However, violating either pre- or post-conditions is unspecified behav…
Contracts are a way to express invariants, "This shall always be true". There are three main things you could do with these invariants, the exact details of how to do them, and whether people should be allowed to specify which of these things to do, and if so whether they can pick only for a whole program, per-file, per-function, or whatever, is separate. 1. Ignore the invariants. You wrote them down, a human can rea…
This is not software engineering. This is an appeal to faith. Software engineering requires precise semantics, not whatever the compiler feels like doing. You can't even declare that this feature has no semantics, because it actually introduces a vector for UB. This is the sort of "feature" that should not be in any language selling itself as an improved C. It would be far better to reduce the scope to the point where the feature can have precise semantics.
The GitHub project has more details: https://github.com/c3lang/c3c Some ways C3 differs from C: - No mandatory header files - New semantic macro system - Module-based namespacing - Slices - Operator overloading - Compile-time reflection - Enhanced compile-time execution - Generics via generic modules - "Result"-based zero-overhead error handling - Defer - Value methods - Associated enum data - No preprocessor - Less…
Earlier quoted context omitted.
Yes, and that same pattern already does exist in C and C++. Asserts that are checked in debug builds but presumed true for optimization in release builds.
Not unless you write your own assert macro using C23 unreachable(), GNU C __builtin_unreachable(), MSVC __assume(0), or the like. The standard one is defined[1] to either explicitly check or completely ignore its argument. [1] https://port70.net/~nsz/c/c11/n1570.html#7.2
In Rust you can wrap core::hint::assert_unchecked similarly.
This seems pretty neat! Still holding out for a language with Go's runtime and compilation and performance characteristics, but language syntax and semantics like Gleam... Maybe one day