4 ms·

I don't think that unsafe constructs are clearly delineated in Zig. @intToPtr and @ptrToInt are in the same namespace as @max. The raw pointer of a slice is a m

I don't think that unsafe constructs are clearly delineated in Zig. @intToPtr and @ptrToInt are in the same namespace as @max. The raw pointer of a slice is a member you can access with mySlice.ptr. A user came into the discord a month or so ago and asked a question about a program they had written where they compared a value to undefined. This is obviously never correct and they meant to make the variable nullable and compare it to null.

Animats 4y ago
> I don't think that unsafe constructs are clearly delineated in Zig. That's the real problem. It's a mixture of safe and unsafe features, with no clear boundary. C++ is like that. The trouble is, people keep using raw pointers and mess up. Read CERT advisories. Most of them come from that class of error. This is the same problem all the attempts to fix up C have hit. Just say no to unsafe code.
- pron 4y ago
  The boundary in Zig is clear, certainly clearer than in C or C++. Unsafe pointers that allow pointer arithmetic have a special type and are far less common than in C++ (and obviously C). Other unsafe operations are clearly grepped, which is not at all the case in C and C++. It is also a much simpler language than C++, which may offers easier understanding and review. The problem with eliminating unsafe code altogether is that doing so has a cost that, in some situations, is not worth it. Sometimes it's a runtime code in memory footprint or CPU resources; sometimes it's a cost in code complexity or development speed, which may have an adverse impact on correctness, which is the real thing we're interested in. Finding the sweet spots among the various options can only be done empirically, and because Zig is so different (it's as different from C as it is from C++ and as different from either as it is from Rust) there's nothing we can extrapolate from. Because it is its very particular combination of features (and lack thereof) that is its message, those who look at a particular aspect and say, oh, this feature is like language X, therefore Zig will have the characteristics of X, completely miss what Zig does. It tries to strike a particular balance between the compiler, the human reader, and the tooling and development experience that can only be considered as a whole. I have no idea if Zig is "good" or if it will be successful -- only time will tell -- but I find the language so refreshing and fascinating because it is a radical departure from everything we've seen in that space in quite a long time. There is no language with a similar mix of features (and lack of features).
  - kps 4y ago
    I fear that it will fail because it rejects information hiding. There isn't all that much new C being written, so it seems counterproductive to renounce the users that (have to) follow coding standards like MISRA C and CERT C.
    - Animats 4y ago
      > information hiding An interesting point, especially at API boundaries. C and Zig not having information hiding is to some extent a feature. C++ is notorious for having information hiding without safety. Almost no other language has that combination.
      - kps 4y ago
        I certainly understand the Zig core's arguments, but I don't think they'll matter in the places where these C coding standards are used. I'm sure an external linter could solve the problem using some naming convention or magic comments, but I'm not sure it'll get far enough for that to be written. [Edit: there does seem to be community interest in metadata annotations for external static analysis https://github.com/ziglang/zig/issues/14656 https://github.com/ziglang/zig/issues/14656 ] Although I only have a beginner knowledge of the language, it seems to me that Zig is just on the edge of being able to provide a nice unification of the C opaque-pointer idiom with other opaque handles (e.g. POSIX file descriptors, GL handles).
    - pron 4y ago
      I can't say that I feel naturally attracted to Zig's position on information hiding (although I do find the whole package a good fit for most of my personal preferences), but it's hard for me to predict how the gestalt of its features will perform in the market, not to mention that the market success of any product is affected by many factors that aren't intrinsic to the product. BTW, how did you reach the conclusion there isn't "all that much new C being written"?
      - kps 4y ago

Animats 4y ago

> I don't think that unsafe constructs are clearly delineated in Zig. That's the real problem. It's a mixture of safe and unsafe features, with no clear boundary. C++ is like that. The trouble is, people keep using raw pointers and mess up. Read CERT advisories. Most of them come from that class of error. This is the same problem all the attempts to fix up C have hit. Just say no to unsafe code.

pron 4y ago
The boundary in Zig is clear, certainly clearer than in C or C++. Unsafe pointers that allow pointer arithmetic have a special type and are far less common than in C++ (and obviously C). Other unsafe operations are clearly grepped, which is not at all the case in C and C++. It is also a much simpler language than C++, which may offers easier understanding and review. The problem with eliminating unsafe code altogether is that doing so has a cost that, in some situations, is not worth it. Sometimes it's a runtime code in memory footprint or CPU resources; sometimes it's a cost in code complexity or development speed, which may have an adverse impact on correctness, which is the real thing we're interested in. Finding the sweet spots among the various options can only be done empirically, and because Zig is so different (it's as different from C as it is from C++ and as different from either as it is from Rust) there's nothing we can extrapolate from. Because it is its very particular combination of features (and lack thereof) that is its message, those who look at a particular aspect and say, oh, this feature is like language X, therefore Zig will have the characteristics of X, completely miss what Zig does. It tries to strike a particular balance between the compiler, the human reader, and the tooling and development experience that can only be considered as a whole. I have no idea if Zig is "good" or if it will be successful -- only time will tell -- but I find the language so refreshing and fascinating because it is a radical departure from everything we've seen in that space in quite a long time. There is no language with a similar mix of features (and lack of features).
- kps 4y ago
  I fear that it will fail because it rejects information hiding. There isn't all that much new C being written, so it seems counterproductive to renounce the users that (have to) follow coding standards like MISRA C and CERT C.
  - Animats 4y ago
    > information hiding An interesting point, especially at API boundaries. C and Zig not having information hiding is to some extent a feature. C++ is notorious for having information hiding without safety. Almost no other language has that combination.
    - kps 4y ago
      I certainly understand the Zig core's arguments, but I don't think they'll matter in the places where these C coding standards are used. I'm sure an external linter could solve the problem using some naming convention or magic comments, but I'm not sure it'll get far enough for that to be written. [Edit: there does seem to be community interest in metadata annotations for external static analysis https://github.com/ziglang/zig/issues/14656 https://github.com/ziglang/zig/issues/14656 ] Although I only have a beginner knowledge of the language, it seems to me that Zig is just on the edge of being able to provide a nice unification of the C opaque-pointer idiom with other opaque handles (e.g. POSIX file descriptors, GL handles).
  - pron 4y ago
    I can't say that I feel naturally attracted to Zig's position on information hiding (although I do find the whole package a good fit for most of my personal preferences), but it's hard for me to predict how the gestalt of its features will perform in the market, not to mention that the market success of any product is affected by many factors that aren't intrinsic to the product. BTW, how did you reach the conclusion there isn't "all that much new C being written"?
    - kps 4y ago