5 ms·
Whenever I see new C++ features I'm all the more impressed with how Zig manages to provide capabilities similar to -- and at least as powerful as -- type templa
by pron 7y ago
Whenever I see new C++ features I'm all the more impressed with how Zig manages to provide capabilities similar to -- and at least as powerful as -- type templates, value templates, constexprs, concepts, and conditional compilation (preprocessor), with a single feature and keyword, without any type/template-level programming, a preprocessor or AST macros (i.e. mini-languages different from the ordinary computation language that one has to learn and can make code quite opaque), all in a language that is about as simple as C and can be fully learned in a day or two.
- fiter 7y agoCould you give or point to some examples?
- pron 7y agohttps://kristoff.it/blog/what-is-zig-comptime/ https://kristoff.it/blog/what-is-zig-comptime/
- lostmsu 7y agoDamn it looks good. I wish it could target and consume .NET or Java.
- unwind 7y agoWhat does that even mean? "Target" I guess could mean that it could compile to code for those virtual machines? That would make some sense although for a language that sets out to compete with/replace C it would be a bit strange. For "consume" I don't know ... do you mean "call into", or something?
- lostmsu 7y agoCorrect on both cases. With .NET I'd love integration with existing types and generics too. Actually, I was just thinking aloud. I don't really mean for Zig authors to target .NET, but rather have .NET Core runtime and C# to have the concept of compile-time values and types.
- pjmlp 7y agoNot strange at all, apparently many still aren't aware that C++/CLI exists. CLR was designed from the start to support C++. Back in the 2000, "Everything.NET" Microsoft, there was the goal of having everything on top of .NET, it just did not play out that way due to the endless Windows/Office vs .NET politics across MS teams. Using C++/CLI is much more productive for interop than manually writing P/Invoke declarations. Or using C++/WinRT to wrap C++ API into COM/UWP libraries. Likewise on Java, microEJ and Android world, with Android Studio, Eclipse, Netbeans and Oracle Studio you can easily do mixed language development and debugging with C and C++. Any systems programming language that wants a place at the table on these platforms, needs to cover these workflows as well as C++ does.
- pron 7y agoJIT compilers already do something like that automatically.
- pjmlp 7y agoThen again, it lacks the eco-system, which is what makes me reach out to C++ when going outside Java/.NET.
- Koshkin 7y agoLooks interesting. I wonder how it compares with Rust and Kotlin.
- voldacar 7y agoThe best part is that Zig accomplishes that without adding a ton of reserved words and the syntax to accompany them, a la C++
- jcelerier 7y ago> capabilities similar to -- and at least as powerful as -- type templates, value templates, constexprs, concepts, and conditional compilation (preprocessor), with a single feature and keyword are you sure ? zig does not seem to have something that looks like concepts (an issue is open : https://github.com/ziglang/zig/issues/1268 https://github.com/ziglang/zig/issues/1268) nor a way to put restrictions on a given type passed to a function or series of function. e.g. it seems that what in C++ would be (with concepts, but the same can be written more verbosely with C++03 templates if needed) void f(IsFoobar auto x) { } void g(IsFoobar auto y) { } would require in zig to have a comptime test for the "foobar" nature of T in every function, which looks like a downgrade and does not expose the requirements cleanly in the function interface.
- pron 7y ago> zig does not seem to have something that looks like concepts ... nor a way to put restrictions on a given type passed to a function or series of function. Of course it does. Just place a comptime assertion on the @TypeOf a var. > would require in zig to have a comptime test for the "foobar" nature of T in every function, which looks like a downgrade and does not expose the requirements cleanly in the function interface. Cleanliness is a matter of personal aesthetic preference, and a rich type specification "in every function" is not less work or less clear than a comptime assertion in every function. In either case you get a clear compilation error. Requirements are never fully specified in the function's interface unless you have dependent types or contracts (both with their own problems and tradeoffs). Even Haskell has partial subroutines. What portions of the spec that is already enforced at compile type should be exposed in the signature -- keeping in mind that it will never be all of them -- is a matter of taste. Zig might shift things around a bit, but the capability to enforce a specification that is at least as strong as structural types at compile-time is already there.
- AndyKelley 7y agoHere's the C++ example from the article: template <class T> concept SignedIntegral = std::is_integral_v<T> && std::is_signed_v<T>; template <SignedIntegral T> // no SFINAE here! void signedIntsOnly(T val) { } Here's the equivalent Zig code. You can run this with `zig test example.zig`. const std = @import("std"); const assert = std.debug.assert; fn signedIntsOnly(val: var) void { comptime assert(std.meta.trait.isSignedInt(@TypeOf(val))); } test "concepts example" { var x: u32 = 1234; signedIntsOnly(x); } This produces the compile error: ../lib/std/debug.zig:221:14: error: unable to evaluate constant expression if (!ok) unreachable; // assertion failure ^ ./example.zig:5:20: note: called from here comptime assert(std.meta.trait.isSignedInt(@TypeOf(val))); ^ ./example.zig:10:19: note: called from here signedIntsOnly(x); ^ ./example.zig:8:26: note: called from here test "concepts example" { ^ It accomplishes the same thing, just a bit more verbose, since it is using the general tools of the language rather than special syntax.