If add optional function arguments? #30678

Hi there, I'm writing the zig code with Version 0.15.1, and when I was writing a function:

fntester(a:i32,b:?i32)i32{b=borelse10;returna+b;}pubfnmain()void{std.debug.print("Result: {d}",.{tester(1)});}

I'm expecting for the result 11, but the compiler returned an error message:

main.zig:9:1: note: function declared here
fn tester(a: i32, b: ?i32) i32 {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
referenced by:
callMain [inlined]: xxx/zig-x86_64-linux/lib/std/start.zig:627:37
callMainWithArgs [inlined]: xxx/zig-x86_64-linux/lib/std/start.zig:587:20
posixCallMainAndExit: xxx/zig-x86_64-linux/lib/std/start.zig:542:36
2 reference(s) hidden; use '-freference-trace=5' to see all references

I'm wondering if there's a plan to add optional function arguments? If ?type represents type or null, then it's silly for compiler to give such a message, since it's optional.

Or maybe we can add default value to the arguments? Just like:

pub fn tester(a: i32 = 1, b: i32 = 10) i32 {
 // ...
}

Thanks!

Considering that zig prefers readability over writability (and thus explicit arguments over implicit/predefined ones), I doubt that feature will be added.

As for your tester function,
a) while the ?i32 type is called optional according to documentation (which imo should maybe be changed), it is more just nullable. It is not optional in the sense that giving it a value isn't required, const a: ?i32; would also fail without giving an explicit value to it.
b) you're also trying to re-assign the argument b to another value, which would also be a compile error, as function arguments are always const. If you want to keep a pattern like you've got there, the common idea is to name the function parameter maybe_b or something similar and then provide the default value with const b = maybe_b orelse DEFAULT_VAL; at the start of the function.

@Rue04 Got that, I just wrote an example to ask if this proposal will be approved.

a) My personal understanding when reading the Optional in the document, is that ?type refers to an optional value, if no value assigned, it should be null, so I guess it can be used in function arguments when I don't want to assign value.

b) I was writing the function in a structure:

constImage=struct{rows:u32=0,cols:u32=0,pixels:[*]Color=&.{},pubfninit(rows:?u32,cols:?u32,pixels:?[*]Color)Image{return{.rows=rowsorelse0,.cols=colsorelse0,.pixels=pixelsorelse&.{},};}pubfnreadFromFile(self:*Image,...,)!void{// ...}};

I was seeking for solutions if I can use the structure by both:

constimage=Image.init(rows,cols,pixels);

and:

varimage=Image.init();image.readFromFile(filename);

Do you have any good advice? I just suppose that a structure shouldn't have two functions for initializing.

My personal understanding when reading the Optional in the document, is that ?type refers to an optional value, if no value assigned, it should be null, so I guess it can be used in function arguments when I don't want to assign value.

I think I'll make an issue suggesting the renaming of optional types to nullable types, to me at least that'd seem less confusing.

For your Image struct, I'd maybe make it so readFromFile returns the image it loaded, so you can do const image = try Image.readFromFile(...);. Alternatively, you could add good default values (like you already have, with 0, 0 and &.{}) and then rewrite the first line in the readFromFile example to var image: Image = .{}; to use the default, empty image.

Not a maintainer, but:

just wanted to mention that Zig doesn't accept language proposals at this time.

Language proposals are not accepted. Please do not open an issue proposing to change the Zig language or syntax.

In future, if you have any questions about your code/improvements, Zig communities got you covered.

Thanks, I'd like to remain init by returning .{} and use image.readFromFile() to setup the image.

By the way I'm wondering when will the stable version (1.0) come out?

@jgonet oh, sorry, I'd like to close that

@aliferne wrote in #30678 (comment):

By the way I'm wondering when will the stable version (1.0) come out?

1.0 will come out when it's "ready" (quoted from Andrew Kelley). The Zig core team doesn't want to rush to 1.0 and wants to ensure everything is great (so that they regret as few decisions as possible when the first "language stable" release is actually out and you can't really change stuff anymore).
On GitHub, there was once a milestone of (bigger) issues that need to be fixed before 1.0. I think that included stuff like formal specification of the Zig programming language, making the main Zig executable no longer depend on LLVM for as much stuff as possible (maybe not the best optimizations, but faster compilations speeds, incremental compilation etc.), a full audit of the standard library + compiler-rt (ensuring stuff is actually usable etc.) and I'm sure I forgot thousand other things.
Suffice it to say, it will not come out in the next year.