Suggestion: Use Try suffix instead of Must prefix

[rcoreilly]

Most users will likely use the "Must" versions of the API. Having to type "Must" for everything is thus unfortunate. It would be better to have the plain methods be of the "Must" variety, and then have the error-returning ones have a suffix like Try. This is the convention I adopted after extensive consideration of these issues :)

[sugarme]

Thanks @rcoreilly for the suggestion. Actually, I was struggling with such naming and still. I chose prefix Must for 2 things:

1. It reminds keep in mind that our program will panic if error (Idiomatic Go has famous thing of error handling here, not sure whether it is good or bad).
2. Keep API name similar to Libtorch C++ APIs as much as possible so that when some issues occurs it easy for us to cross-referencing.

I am not sure about the "convention" you mentioned above. Can you elaborate more? I took Must concept from Go standard library regexp.

Anyway, I leave it open as you have a valid point on API consumer point of view there until we have further concrete idea.

[rcoreilly]

Here's a bit more explanation of the logic: https://github.com/goki/ki/wiki/Naming

If you need a solid "Go" motivation: the single strongest feature of Go is simplicity, and the standard naming conventions are part of that: keeping names as short and clear as possible. If you add "Must" to every single name, then it kind of loses its value I think, and it becomes a source of visual distraction in the code. Maybe just try rewriting some of your example code and look at the difference. I bet it looks a lot cleaner and simpler without "Must" everywhere.

The Regexp case is a bit different because initializing a regexp is usually fairly rare, so it doesn't have much impact on the code overall. But the reason I wrote this issue is just from a quick glance at the README.md, all the "Must" just jumped out at me! "too Musty" :)

[sugarme]

Yeah, quite "musty" :). However, some may argue that the better way of using APIs is return "error" instead of "panic" so that you have a chance to handle error. If you try gotch with GopherNote you will see that you need to handle error instead of let's it panic otherwise Go kernel will die right away. Back to your suggestion of using suffix, can you please give me a concrete example? Thanks.

[rcoreilly]

Here's an example:

func (ts *Tensor) SizeTry() ([]int64, error) {
...
}

func (ts *Tensor) Size() []int64 {
...
}

So, as a user, if you think you might have some kind of error, you use the Try version, and check the err, but otherwise use the "plain" version.

Also, the main reason we needed to have two different versions (non-Try and Try) for the GoKi case was when accessing elements in tree structures that needed to then be type-cast into their proper type. This also extends to cases where you want to use the return value directly in expressions of any sort. So, for cases where the return value would typically only be used as an initializer, and not enter into any kind of expression, then I would recommend just going with the Go convention of returning the additional error value, which can be easily ignored in initializers. I don't know how many cases that might apply to here.

[yam8511]

In my opinion, Must is common and familiar for the gopher community. For example, there're many Must prefix naming function in a lot of golang native library and third-party package. Official Naming Suggestion

Finally, this is just my opinion. 😃

[sugarme]

close for now as happy with prefix Must APIs.