Questions that remained after reading all the Overview on the Odin programming language.

[joaocarvalhoopen]

Questions that remained after reading all the Overview on the Odin programming language.

1. The way a language does it's error processing in functions is one of the thing it's more important in a language, how are the Odin Error processing patterns? How does it all work in a real aplication with functions calling functions inside oen another and passing returning the errors? How do it compares with something like C, exceptions in C++, Error handling propagation beween methods and functions in Rust, and "defer" in GO?
Those patterns of use cases should be highligthed and linked in a proiminent way to be studied by all. Because it's importante, and is a subject in which C lack a lot of power for Error handling.

I sow this on the documentation:

f, err := os.open("my_file.txt")
if err != os.ERROR_NONE {
	// handle error
}
defer os.close(f)
// rest of code

but not on the patterns of code for propagation of errors between functrion calls and returns or_return in nested function calls. What are the stategies and the advice from the more senior in Odin?
Can you please explain and high light it in the documentation that major point of how it works in Odin?

2. Can a iterator in a "for" loop be used for a custom user struct collection type?
How can this iterator be implemented on a type?
What is the convention?

3. The reverse iterator transversal is kind of awkward :-)

#reverse for x in array {
	fmt.println(x) // 50 40 30 20 10
}

will there be the possibility to suport different uses in iterators?

like #reverse, #increment 3, #get_by_ref, #get_by_value

And how can I compose them?

Is this precedure or function type of iterators supported? Will it work?

for _, i in incr_by( reverse( some_slice ), 3 ) {
	some_slice[i] = something
}  

or even:

my_vec := collect_to_vec( incr_by( reverse( some_slice ), 3 ) )

or even map, reduce, join, split and that kind of functionally programming inpaired and on other front automatic parallel split of work in multiple threads:

my_vec_2 := map_func( my_vec, square )

4. I beg you, to support some how, in a switch on a case on strings, cstrings and normal strings. This is a so much useful use os a switch in day to day programming. It's sintatic sugar, but is really nice and simplifies the control flow of many small prototipe programs.

f : string = "bla" 
switch f {
   case "bla" : fmt.println("bla")
   case "bli" : fmt.println("bli")
   case "blo" : fmt.println("blo")
   case "blu" : fmt.println("blu")
   case:        fmt.println("Error, string not found!")
}

5. From the documentation:

in - set membership (e in A, A contains element e)

Used for bit_set types and map types

not_in - not set membership (e not_in A, A does not contain e)

Used for bit_set types and map types

Question: Why only "bit_set's" and "map" types and not "arrays" and "vectors", all collections should have a contains procedure that could be maped to a "in" operator automatically.

6. I don't understand what is the Maybe Union, where do you use it? In what context? How do you use it? A exemplo is in the Overview but it is not really clear, at least to me.

Maybe

Maybe :: union($T: typeid) {}

How does it passes trought functions? Where is the Some() and the None of Rust in this Option type?

halve :: proc(n: int) -> Maybe(int) {
	if n % 2 != 0 do return nil
	return n / 2
}

half, ok := halve(2).?
if ok do fmt.println(half)       // 1
half, ok = halve(3).?
if !ok do fmt.println("3/2 isn't an int")

n := halve(4).? or_else 0
fmt.println(n)                   // 2

7. Why assigning to a struct field inside a element of a map is PROIBITED?????
What's the reson of this limitation? I think that it should work well, right?

In the Maps it is written:

Modifying existing map slots needs to be done in two steps. Hovewer assigning to a struct field is prohibited.

Test :: struct {
	x: int,
	y: int,
}

m := map[string]Test{
	"Bob" = { 0, 0 },
	"Chloe" = { 1, 1 },
}

value, ok := &m["Bob"]
if ok {
	value^ = { 2, 2 }
}

fmt.println(m["Bob"]) // { 2, 2 }
m["Bob"] = { 3, 3 }
fmt.println(m["Bob"]) // { 3, 3 }
m["Chloe"].x = 0 // PROHIBITED

What a wonderful programming language and a really nice simple designed language.
Things are logical and make sense.

Thank you very much,

Best regards,
João Carvalho