I noticed in the core branch that Maybe exists as a member of an enum defining the type in a type info struct. What is the Maybe type? Is it similar to other languages optional types? Is it fully implemented yet and what exactly is the current syntax for it.
I won't keep hammering you with syntax questions but this would be useful for other programmers trying out the language to know as well.
Thanks.
I won't keep hammering you with syntax questions but this would be useful for other programmers trying out the language to know as well.
Thanks.
Edited by novus1044
on
Maybe or option types are pretty much the base type plus a bool. They do work however, I'm thinking about removing.
The current syntax is this:
In a language with multiple return values and C-like* memory handling, I don't think maybe types are not that useful.
If people can change my mind by making maybe types in keeping with the language, I'll keep them.
*C-like as in no automatic memory management (but that's still not entire true with the custom allocation system).
The current syntax is this:
1 2 3 4 | x: ?int; // maybe int x = nil; // zero value x = 123; // store a value v, ok := x?; // "demaybe" it where `ok` is the boolean checking if has a value defined |
In a language with multiple return values and C-like* memory handling, I don't think maybe types are not that useful.
If people can change my mind by making maybe types in keeping with the language, I'll keep them.
*C-like as in no automatic memory management (but that's still not entire true with the custom allocation system).
I will preface the following statements with the caveat that I am not a professional developer.
With that said, I agree that optional pointers may not be entirely useful given you can return multiple values.
The only idea I can really think of is using the ? operator as a signaling mechanism that basically collapses to a ^ pointer.
To be specific, you could do something like the following:
You would still deref the pointer using the ^ operator.
The ? would simply signal that the pointer could potentially be null or nil so you as a the programmer should insert a null/nil check.
I am not sure the utility of such a mechanism, but I figured I would throw it out there and see what you think.
With that said, I agree that optional pointers may not be entirely useful given you can return multiple values.
The only idea I can really think of is using the ? operator as a signaling mechanism that basically collapses to a ^ pointer.
To be specific, you could do something like the following:
1 | x: ?int; // an optional pointer to an int, where ? has no language level effect |
You would still deref the pointer using the ^ operator.
The ? would simply signal that the pointer could potentially be null or nil so you as a the programmer should insert a null/nil check.
I am not sure the utility of such a mechanism, but I figured I would throw it out there and see what you think.
Edited by novus1044
on
Which is still a little redundant. `?int` is stored internally as `struct{int, bool}` not `^int`. A null/nil pointer deference isn't usually that much of a problem and I usually assert the hell out of the cases when it could be an unexpected problem. I know other programmers may not agree but it's not really a problem for me (or it's quick to solve with the debugger).
n.b. I understand what maybe/option types solve as any type system with a "special null" is problematic.
n.b. I understand what maybe/option types solve as any type system with a "special null" is problematic.
I actually use asserts in my C code as well to cover the cases where I may receive a null pointer (ex. an argument passed to a function). I think we were talking past each other a little bit. I meant maybe you could change the ? operator's representation to be the exact same as the ^. To the compiler ^ and ? would be identical. It would be purely a mechanism to signal to a programmer that a pointer may be null.
After taking your post into consideration, the only benefit may be in clarifying return values to functions where you would have something like the following:
// Here the use of the ? instead of ^ signals that we may be returning a null pointer.
//If I store the result of the call in on the caller's stack I should make sure to check for a null/nil.
vs.
//You would use the ^ here if you were for certain going to return a valid pointer and therefore wouldn't
//have to check the return value for the function.
The code above is just to clarify my previous point. I am not strongly pushing for the optional type.
I do agree with you though null pointer deref isn't typically a big time sink to fix at least that has been my experience. It may very well be different for more experienced developers working in a more complex code base.
After taking your post into consideration, the only benefit may be in clarifying return values to functions where you would have something like the following:
// Here the use of the ? instead of ^ signals that we may be returning a null pointer.
//If I store the result of the call in on the caller's stack I should make sure to check for a null/nil.
1 | search :: proc( /*args*/ ) -> ?Value_Type |
vs.
//You would use the ^ here if you were for certain going to return a valid pointer and therefore wouldn't
//have to check the return value for the function.
1 | search :: proc( /*args/ ) -> ^Value_Type |
The code above is just to clarify my previous point. I am not strongly pushing for the optional type.
I do agree with you though null pointer deref isn't typically a big time sink to fix at least that has been my experience. It may very well be different for more experienced developers working in a more complex code base.
Edited by novus1044
on
For C, clang has type attributes _Nonnull, _Nullable and _Null_unspecified for use in function prototypes. All they do is help the static analysis along and issue a warning if it can detect misuse. It's a good idea, particularly at API boundaries where you can just read off the behaviour with respect to pointers without having to hope its documented.
I prefer that to doing it in the type system because it's transparent at the point of use--no 'constructing' a container type that's optimised away
I prefer that to doing it in the type system because it's transparent at the point of use--no 'constructing' a container type that's optimised away
I've actually removed maybe types from the language after all of this.
I understand what you are saying graeme but that seems to be a bad API rather than a bad language. If I want to use `?` to mean a pointer dereferenced that get checked or something, that would be easy to add but as this isn't a "very high level" language, it would cause other problems such as verbose syntax.
I understand what you are saying graeme but that seems to be a bad API rather than a bad language. If I want to use `?` to mean a pointer dereferenced that get checked or something, that would be easy to add but as this isn't a "very high level" language, it would cause other problems such as verbose syntax.