Again - I am interested in the "why they were designed this way".
@Axel Wagner: > checking for nil: My recommendation is to just not do that That is the reason why I gave the examples with the standard library. Within very similar circumstances - a logging framework I need to ensure that adding a log statement would not cause a problem. We may argue whose fault a panic within a particular call is - but there are cases when you do not want a call to cause panic. The fact the standard library does this - for fmt and logging is a very strong argument that there are cases where this is necessary. In very similar circumstances I need to do something similar. Note that a caller may not be the real cause of the problem as the interface value may have been passed to them. The same argument applies to them - they have no safe way to decide whether it is safe to pass the value to the function expecting the interface. @Burak Serdar: > The fact that an interface may contain a nil value... Method sets are not > related to this. I disagree with you on this. See https://go.dev/play/p/N20xLUeaVMz In this case the receiver is declared on a pointer. The interface definitely contains a nil value but does not cause a panic. - A method defined on a type is counted in the method set of the pointer - Therefore the pointer can be passed as an argument to the function since it is considered to have the method (and thus fulfil the interface) - At the point the interface method is called - the compiler does dereference to get the value and since it is nil we get a panic Compare this when the method is on the pointer. Again the pointer fulfils the interface however at the point of call there is no need for dereference (at least in this particular method). Therefore there is no panic. I think it is exactly the method set logic that causes this. Compare it with this slightly changed example https://go.dev/play/p/k1zq6vMWwVI The method is still on the pointer but we pass a pointer to that pointer rather than the original pointer. In this case the whole thing does not compile at all - exactly as the spec says: @The method set of a pointer to a defined type T (@@where T is neither a pointer nor an interface@@) is the set of all methods declared with receiver *T or T.@ We get the increase of method sets on moving from a non-pointer to pointer. There is no such increase when we go from a pointer to a pointer to a pointer. Therefore - why were method sets designed this way? It was totally possible to not do the automatic inclusion of methods on non pointer types to the method set of pointers to the types. Kind regards: al_shopov -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAP6f5MkAO5VfC9WhCMy%3DR%2BfCgoQefjFs%2BX01KRU1rK2adwTj5A%40mail.gmail.com.
