Maybe change the optional declaration syntax?
Currently we have return io::EOF?;, but this complicates the grammar. Consider alternatives:
return ^io::EOF;
return %io::EOF;
return ?io::EOF;
return /io::EOF;
return .io::EOF;
return io::EOF~;
return io::EOF~~;
return io::EOF@;
return io::EOF$;
return io::EOF#;
return [io::EOF];
return (?)io::EOF;
return ?(io::EOF);
return io::EOF#?;
return io::EO?$;
return %%io::EOF%%;
Also
int? a = foo() ?? ^io::EOF;
int? a = foo() ?? %io::EOF;
int? a = foo() ?? ?io::EOF;
int? a = foo() ?? /io::EOF;
int? a = foo() ?? .io::EOF;
int? a = foo() ?? io::EOF~;
int? a = foo() ?? io::EOF~~;
int? a = foo() ?? io::EOF@;
int? a = foo() ?? io::EOF$;
int? a = foo() ?? io::EOF#;
int? a = foo() ?? [io::EOF];
int? a = foo() ?? (?)io::EOF;
int? a = foo() ?? ?(io::EOF);
int? a = foo() ?? io::EOF#?;
int? a = foo() ?? io::EO?$;
int? a = foo() ?? %%io::EOF%%;
Let's make an exhaustive list of alternatives.
is there already a #x prefix operator?
maybe add #io::EOF to the list if not (Though, might just be partial to prefix operators over postfix ones)
In use. #foo would be a lazily evaluated argument.
Ahh yeah, I forgot about that
I love return io::EOF?; as it is.
But if you really want to change, I vote for
return ?io::EOF;
int? a = foo() ?? ?io::EOF;
// or a better 'or_else'
int? a = foo() ||| ?io::EOF;
If it does not complicate things, IMO using direct return (return io::EOF;, int? a = foo() ?? io::EOF;) would be better.
If an error indicator is really needed and postfix ? must be changed, I would also vote for prefix ? (return ?io::EOF;, int? a = foo() ?? ?io::EOF;).
After some time I conclude that ?-prefix is best. To add more readability, I also propose \\ as a replacement of ??.
I guess it looks nice:
int? index = find_index(array) \\ ?NOT_FOUND!!;
If it does not complicate things, IMO using direct return (
return io::EOF;,int? a = foo() ?? io::EOF;) would be better.If an error indicator is really needed and postfix
?must be changed, I would also vote for prefix?(return ?io::EOF;,int? a = foo() ?? ?io::EOF;).
A counterpoint to the first part that lerno put in the discord, what does this do?
fn fault? some_function() => io:EOF;
// or a better 'or_else' int? a = foo() ||| ?io::EOF;
||| is compile time || where the right hand side is not evaluated if the left hand side is constant true.
Compare:
fn fault? some_function() => io:EOF~;
or
fn fault? some_function() => ?io:EOF;
// or a better 'or_else' int? a = foo() ||| ?io::EOF;
|||is compile time||where the right hand side is not evaluated if the left hand side is constant true.
Can we consider \\ as a replacement for ?? ? \\ has a similar look with '||' so it even may be easier to remeber.
int? a = foo() \\ ?io::EOF;
What I dislike about ?io::EOF is that it combines poorly with ?? visually. Compare these:
int? a = foo() ?? ?io::EOF;
/* ... */
int? a = foo() ?? ^io::EOF;
/* ... */
int? a = foo() ?? (?)io::EOF;
No more opinions?
No more opinions?
Remove optional from the language completely and implement it in std like C++17 std::optional.
Wat
perhaps ?? could be replaced by else or otherwise, or_else, default, then, if_not, lest, or ... then the ? prefix would work
int? a = foo() else ?io::EOF;
int? a = foo() otherwise ?io::EOF;
int? a = foo() or_else ?io::EOF;
int? a = foo() default ?io::EOF;
int? a = foo() then ?io::EOF;
int? a = foo() if_not ?io::EOF;
int? a = foo() lest ?io::EOF;
int? a = foo() or ?io::EOF;
or_else quite fits with existing foreach_r, but I'm not sure if anything with else is intuitive for optional semantics... but for regular person it would probably more obvious then \\.
I wonder if Christoffer would be ok with adding another keyword.
No more opinions?
Remove optional from the language completely and implement it in std like C++17
std::optional.
If speaking seriosly:
- C3 already has traditional optionals with
Maybe - C3 wants strongly differentiate between a potential empty value (Maybe) and value that can not be gotten due some issues (Optional)
- Moreover, the mechanism with implisitly unwraping options is extremely good so the lang will 100% stay with that
perhaps
??could be replaced byelseorotherwise,or_else,default,then,if_not,lest,or... then the?prefix would work
No, we'll keep ??, I'm aware of those alternatives, but find them less clear.
With ?? standing, I found ?(io::EOF) fine because:
?pointing to optional semantics- due braces, pops out with
??and shows order with!and!! - actually looks like wrapping to on optional (I found
(?)weird)
?(io::EOF) is not bad.
?(io:EOF)
vs
(?)io::EOF
I think it would be easier for the user to see they got it right with (?), for example a longer fault name you would need to parse to the end of the line to see if had a matching brace:
it also seems intuitive to cast to a fault (?), even if it's not exactly what's going on
faultdef MEMORY_CORRUPTION_IN_CORE;
int? reading_data = ?(MEMORY_CORRUPTION_IN_CORE);
vs
faultdef MEMORY_CORRUPTION_IN_CORE;
int? reading_data = (?)MEMORY_CORRUPTION_IN_CORE;
mistakes could more easily happen like this for example:
faultdef MEMORY_CORRUPTION_IN_CORE;
int? reading_data = ?(MEMORY_CORRUPTION_IN_CORE;
or with nested function calls it could get messy
int? reading_data = ?(some_function(arg1, arg2, arg3, arg4));
vs
int? reading_data = (?)some_function(arg1, arg2, arg3, arg4);
I can live with (?), it has a benefits. The most important is to end up with something containing the ?.
in c#,
int? y = 3;
int useY = y ?? 0;
in c#,
int? y = 3; int useY = y ?? 0;
How this exactly this corresponds to the topic? (C3 already has ??, we are figuring out operator for fault -> optional conversion)