-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
first draft of the language specification #75
Comments
Is there a wiki to discuss language features / syntax? |
Sure, I mean the wiki's open. Have at it. Feel free to ask questions and make proposals here or in other or new issues too. |
My two major comments are: The const in front of the type when you use suffix types is inconsistent, I would have it in the suffix. The maybe type should work like a monad. Also somehow the percent operator and the mix between references, pointers and nullable doesn't make a lot of sense to me. Why would you be able to maybe an i32 that is not a pointer? A reference should never be null also. |
Can you give some code examples of how it's inconsistent? I'm a visual learner. Also zig doesn't have suffix types, only prefix types.
Can you spell this out in more detail for someone who isn't super keen on functional programming?
Zig doesn't have references, only pointers. You can make any type nullable if you want to introduce a null state to the set of possible values. The generalized concept makes sense independent of pointers. |
Are you talking about: var a : i32;
const b : i32; vs something like: let a : i32;
let b : const i32; If so, the reason for this is that the const-ness of a symbol is not a property of its type, but rather of its declaration in context. If a "variable" is declared constant, it means you can't assign to it. That idea doesn't really have anything to do with its type. In zig, you can't declare a field of a struct const. Either the whole struct is const, as determined by its usage in context, or the whole thing is variable. Likewise, you can't declare an array of constant values. Either the array itself is declared const, or the whole thing is variable. If Unlike structs and arrays, which are "by-val" compound types, pointers do not embed their "child type", and so their const-ness is independent of their target's const-ness. That is why the |
Yeah thats what I meant. I was a bit brief as I'm a cellphone. Still the compiler can check that a const pointee is not mutated through p: const*T. So WRT to const it boilds down to const / let/ var. If using const then it would be great to also be able to use const on the right side so the typechecker can avoid mutating the pointee through that pointer as C++ would do. About the monads I will respond later. |
Are you suggesting that this be allowed: var a : i32;
const b : i32;
const c : const i32; // same as b
var d : const i32; // probably not allowed? |
According to your comments I thought that const p: const * i32 wouldn't be allowed. How would a pointer to a const array of char be declared? const s: []u8 = "something in .rodata" p can't be changed, nor the data it points. Equivalent to const * char const in C++... I'm just trying to understand the logic behind the type syntax. Regarding monads I would suggest watching this: https://www.youtube.com/watch?v=Mw_Jnn_Y5iA&feature=youtu.be This is very pictorical (swift based): http://www.mokacoding.com/blog/functor-applicative-monads-in-pictures/ And more: |
const s = "something in .rodata"; // @typeof(s) is `[20]u8`
const p = &s[0]; // @typeof(p) is `&const u8` As for monads, you made this claim:
Can you provide code examples to demonstrate your proposal? |
Here's the repo: https://github.com/ziglang/zig-spec Once we have a first draft, this issue can be closed, and that repository can be used to track progress towards completion of the spec. |
It has to happen sometime. Probably not until a proof of concept is already working and the language isn't constantly changing.
The text was updated successfully, but these errors were encountered: