The AddAtEnd function of singlylinkedlist has a fixed argument type of int

[zhuobo]

Describe the bug
The AddAtEnd function of singlylinkedlist has a fixed argument type of int, so it can only add nodes of type int to the single linked list.
file: structure/linkedlist/singlyinkedlist.go
function: AddAtEnd(val int)

Expected behavior
Any type of value can be added to a single linked list.

[tjgurwara99]

This requires you to change the whole implementation and when using you would have to manually type check everything. This is a learning repository so I don't think it makes sense to make using linked list complicated.

Consider this:

type Ll struct {
    val interface{}
}

func check(list []Ll) bool {
     for _, li := range list {
         switch li.(type) {
         case Type1:
               ...
         case Type2:
               ...
          ...
         }
     }
 }

this is convoluted for a new beginner. So in my opinion, we should not make things complicated for beginners.

@siriak @raklaptudirm thoughts?

[raklaptudirm]

Absolutely. These types of changes make sense for this repository only when the algorithm is not that complicated to turn into a generic.

[siriak]

Shall we implement this one once generics are in place?

[raklaptudirm]

Depends on how they are implemented, I do not think their syntax is finalized.

[siriak]

Well, having thought of it for a while, I don't think there's a need for a separate issue for every part where we could use generics in the future as there are a lot of such places

[tjgurwara99]

I do not think their syntax is finalized.

I think the syntax and design has been accepted. But the generics in Go will not be similar to generics in other languages. In fact, they are using a completely new approach of using contract (which I think are very very similar to interfaces - I think of them as interfaces on interfaces). The concept is similar to the following (if I remember correctly):

type Comparable interface {
	type int, int32, int64 ...
}

and based on that the implementation would actually be concrete and not generic (I believe). This implementation is very much suitable for problems like sorting algorithms but not quite suitable for this IMO.

Well, having thought of it for a while, I don't think there's a need for a separate issue for every part where we could use generics in the future as there are a lot of such places

I agree. If we can implement things using generics, we should definitely do it if and only if it is feasible and easy to understand for beginners without breaking things 😂

But I still think the generic approach would be very involved and might be difficult. Alas, once the Go1.18 is out, I would still personally like to experiment making algorithms in this repo generic 😂

[tjgurwara99]

Apologies, I take back what I said, they will be somewhat similar to how they work on other languages. The only difference would be the implementation details. I think it's currently looking very promising. I'm excited for this now!!