4 ms·

C3 looks promising, but any language that supports nulls needs null-restricted types, not whatever those contract comments are. If I wanted to have to null-chec

C3 looks promising, but any language that supports nulls needs null-restricted types, not whatever those contract comments are. If I wanted to have to null-check everything, or YOLO it, I would just write Java... and even Java is seeking to fix this: https://openjdk.org/jeps/8303099 https://openjdk.org/jeps/8303099

90s_dev 1y ago
I'm on the fence about function contracts like this. I've seen them for a decade in other languages, but never really used them, so I can't say how I feel about them. But having them be inside comments is just weird.
- Jtsummers 1y ago
  It's a directive that happens to be placed at the tail end of a comment. Reading the documentation the doc comment stops being a comment-proper with the first @-directive, after that it's a list of directives. SPARK started in comments, ACSL is placed in specially marked comments. SPARK 2014 moved into Ada proper using Ada 2012 features (aspects). The difference between SPARK 2014's annotation and this is basically, are the annotations above the function or after the function declaration?
- joshring2 1y ago
  It is different yes, having read a good amount of it by now I find it work's pretty well in practice. It means you can incrementally adopt them if you like and code with or without them looks quite similar assuming you documented your code, the function signatures look the same as well which I appreciate.
lerno 1y ago
It's an interesting problem. Originally I experimented with both having `` and `&` syntax, so `int&` being a ref (non null) and `int` being a pointer. The thing you notice then are two things: 1. You want almost all pointer parameters non null. 2. Non-null variables is very hard to fit in a language without constructors. Approaches to avoid constructors/destructors such as ZII play very poorly with ref values as well. What you end up with is some period of time where a value is quasi valid - since non-null types need to be assigned and it's in a broken state before it's initially assigned. It's certainly possible to create generic "type safe" non-null types in C3, but they are not baked into the language.
- aidenn0 1y ago
  > Approaches to avoid constructors/destructors such as ZII play very poorly with ref values as well. What you end up with is some period of time where a value is quasi valid - since non-null types need to be assigned and it's in a broken state before it's initially assigned. I don't see that as a problem; don't separate declaration from assignment and it will never be unassigned. Then a ZII non-null pointer is always a compile-time error.
  - wavemode 1y ago
    > don't separate declaration from assignment and it will never be unassigned That's tricky when you want to write algorithms where you can start with an uninitialized object and are guaranteed to have initialized the object by the time the algorithm completes. (Simplest example - create an array B which contains the elements of array A in reverse order.) You can either allow declaring B uninitialized (which can be a safety hazard) or force B to be given initial values for every element (which can be a big waste of time for large arrays).
    - Maxatar 1y ago
      I don't think that's much of an issue. If you need deferred initialization then stick to a pointer and then once the pointer is initialized shadow it with a reference. int* pre_foo = null; ... initialize pre_foo ... int& foo = *pre_foo;
  - lerno 1y ago
    I don't quite see what you mean. As an example, let's say you use ZII and allocate 100 objects in a single allocation. These are now zero initialized and so either invalid (which should not happen) or do not hold non-null types. Can you explain how you intend this scenario to be resolved in your case? Otherwise it's quite straightforward that they have an uninitialized state (zero) and are then wired up when used. Trying to prevent null pointers here is something that the program to do. However, making the compiler guarantee without requiring constructors it is a challenge I don't know how to tackle.
netbioserror 1y ago
Nim solves this problem by only having two explicit, restricted nullable types: Pointers and references. Pointers are manually managed, references are automatically managed, both start as nil and must have their referenced objects instantiated manually. The entire rest of the language is built on pass-by-value using stack values and stack-managed hidden unique pointers. You basically never actually need to use a ref or a pointer unless you're building an interface to a C or C++ library. I having written a 40k line production application with no reference or pointer types anywhere. Almost any case you'd need is covered by simply passing a compound type or dynamic container as a mutable value, where it's impossible to perform any kind of pointer or reference semantics on it. The lifetime is already managed, so semantically it's just a value.
monkeyelite 1y ago
Why is there only one way to solve a problem?

90s_dev 1y ago

I'm on the fence about function contracts like this. I've seen them for a decade in other languages, but never really used them, so I can't say how I feel about them. But having them be inside comments is just weird.

Jtsummers 1y ago
It's a directive that happens to be placed at the tail end of a comment. Reading the documentation the doc comment stops being a comment-proper with the first @-directive, after that it's a list of directives. SPARK started in comments, ACSL is placed in specially marked comments. SPARK 2014 moved into Ada proper using Ada 2012 features (aspects). The difference between SPARK 2014's annotation and this is basically, are the annotations above the function or after the function declaration?
joshring2 1y ago
It is different yes, having read a good amount of it by now I find it work's pretty well in practice. It means you can incrementally adopt them if you like and code with or without them looks quite similar assuming you documented your code, the function signatures look the same as well which I appreciate.

lerno 1y ago

It's an interesting problem. Originally I experimented with both having `` and `&` syntax, so `int&` being a ref (non null) and `int` being a pointer. The thing you notice then are two things: 1. You want almost all pointer parameters non null. 2. Non-null variables is very hard to fit in a language without constructors. Approaches to avoid constructors/destructors such as ZII play very poorly with ref values as well. What you end up with is some period of time where a value is quasi valid - since non-null types need to be assigned and it's in a broken state before it's initially assigned. It's certainly possible to create generic "type safe" non-null types in C3, but they are not baked into the language.

aidenn0 1y ago
> Approaches to avoid constructors/destructors such as ZII play very poorly with ref values as well. What you end up with is some period of time where a value is quasi valid - since non-null types need to be assigned and it's in a broken state before it's initially assigned. I don't see that as a problem; don't separate declaration from assignment and it will never be unassigned. Then a ZII non-null pointer is always a compile-time error.
- wavemode 1y ago
  > don't separate declaration from assignment and it will never be unassigned That's tricky when you want to write algorithms where you can start with an uninitialized object and are guaranteed to have initialized the object by the time the algorithm completes. (Simplest example - create an array B which contains the elements of array A in reverse order.) You can either allow declaring B uninitialized (which can be a safety hazard) or force B to be given initial values for every element (which can be a big waste of time for large arrays).
  - Maxatar 1y ago
    I don't think that's much of an issue. If you need deferred initialization then stick to a pointer and then once the pointer is initialized shadow it with a reference. int* pre_foo = null; ... initialize pre_foo ... int& foo = *pre_foo;
- lerno 1y ago
  I don't quite see what you mean. As an example, let's say you use ZII and allocate 100 objects in a single allocation. These are now zero initialized and so either invalid (which should not happen) or do not hold non-null types. Can you explain how you intend this scenario to be resolved in your case? Otherwise it's quite straightforward that they have an uninitialized state (zero) and are then wired up when used. Trying to prevent null pointers here is something that the program to do. However, making the compiler guarantee without requiring constructors it is a challenge I don't know how to tackle.

netbioserror 1y ago

Nim solves this problem by only having two explicit, restricted nullable types: Pointers and references. Pointers are manually managed, references are automatically managed, both start as nil and must have their referenced objects instantiated manually. The entire rest of the language is built on pass-by-value using stack values and stack-managed hidden unique pointers. You basically never actually need to use a ref or a pointer unless you're building an interface to a C or C++ library. I having written a 40k line production application with no reference or pointer types anywhere. Almost any case you'd need is covered by simply passing a compound type or dynamic container as a mutable value, where it's impossible to perform any kind of pointer or reference semantics on it. The lifetime is already managed, so semantically it's just a value.

monkeyelite 1y ago

Why is there only one way to solve a problem?