Both `slist` and `dlist` have methods which return unexported return types about gogu HOT 3 CLOSED

Your point stands up perfectly fine in many aspects. The ultimate argument is to pass out a returned value to another function without knowing it's type, so it's definitely worth to check it out the possibilities. I didn't wanted to expose the node type per-se, because that was the whole point of the constructor method, but if we put on balance what we can loose over what we can gain by exporting the node type (a.k.a. making it public) then definitely I would stick to make it public instead of eliminating (at least from a few methods) the return type. As a conclusion I will take into consideration your arguments and an updated version will follow soon.

from gogu.

I analyzed the possibilities, but I'm a little bit uncertain why you are against returning a private type from a public method even if the struct holding the inner implementation of the node type is also private. The reason why I opted for this approach is that (as you certainly know) in Go it's possible to return a private type as a public method return type, though as far as I know in Java this is not possible.

I admit, that some of public methods does not strictly require to return the node element, and from API standpoint probably is much cleaner to avoid returning the node element on methods like Unshift, Append or Replace because we already know the node we are operating on, so as a matter of these methods I have refactored the code.

The Find method can be useful to obtain a certain node by using a value as argument, but when we need to know the first or last node (used on queue package for ex.) we must return the node element also, like on Shift or Pop methods.

So please share your thoughts if you have any arguments against my point of view.

from gogu.

The reason behind my point of view was, as you also mentioned, confusion.

For example, if we try using the single linked list in another package as follows:

package main

import (
	"fmt"
	"github.com/esimov/gogu/list"
)

func main() {
	lst := list.SList[string]{}
	lst.Append("one")
	lst.Append("two")
	lst.Append("tree")

	node, found := lst.Find("two")

	if found {
		fmt.Print(node)
		doSomethingWithNode(node) // Note: we are passing the found node to another function
	}
}

func doSomethingWithNode(node interface{}) { // The type has to be interface or any
	fmt.Print(node)
}

We can see that while we get a node as returned result, this is kind of annoying to be used. If we want to pass it around in our code, we have to accept argument having the type of interface or any.
I totally understand your reasoning behind returning this type and I agree that it might be useful in cases those cases point out in your answer. As an end-user of this library, I feel like I should be aware of those cases in order to use the library effectively.

In terms of API design, I think this StackOverflow answer puts it best: "the function signature does not clearly convey its scope of use". I feel like this kind of underlines my previous point, in a sense that the API is designed in a way to adhere to the internals of another component (such as queue). Now, obviously, design decisions are not something which we can think about as good or bad. There are points and counterpoints for every one of them, ultimately it is up to you to chose what you think is the best.

Lastly, the latest versions of Goland complain about returning of unexported types. There is an entire thread on Reddit about this issue: https://www.reddit.com/r/golang/comments/xurmnl/return_unexported_type/
Also, as a counterpoint, neither go vet or Staticcheck complain about this. So there is that :)

Ultimately, the decision is up to you. I don't strongly stand behind any of my initial points, I understand that you had other reasons behind taking the current decision.

from gogu.