Problem accumulating/appending values in an array using recursion with Go












-1















First of all, this is my first non-dummy program using Go. Any recommendation will be appreciated.



Code description:



I want to retrieve all the information from an API where the information is being paginated. So I want to iterate through all the pages in order to get all the information.



This is what I did so far:



I have the these two functions:



func request(requestData *RequestData) *ProjectsResponse {

client := &http.Client{
Timeout: time.Second * 10,
}

projects := *ProjectsResponse{}
innerRequest(client, requestData.URL, projects)

return projects
}

func innerRequest(client *http.Client, URL string, projects *ProjectsResponse) {

if URL == "" {
return
}

req, err := http.NewRequest("GET", URL, nil)
if err != nil {
log.Printf("Request creation failed with error %sn", err)
}
req.Header.Add("Private-Token", os.Getenv("API_KEY"))

res, err := client.Do(req)
log.Printf("Executing request: %s", req.URL)

if err != nil {
log.Printf("The HTTP request failed with error %sn", err)
}
data, _ := ioutil.ReadAll(res.Body)
var response ProjectsResponse
err = json.Unmarshal(data, &response)

if err != nil {
log.Printf("Unmarshalling failed with error %sn", err)
}

projects = append(projects, &response)
pagingData := getPageInformation(res)
innerRequest(client, pagingData.NextLink, projects)
}


Undesired behavior:



The values in the projects *ProjectsResponse array are being appended on each iteration of the recursion, but when the recursion ends I get an empty array list. So, somehow after the innerRequests ends, in the project variable inside the request method I get nothing.



Hope somebody and spot my mistake.
Thanks in advance.










share|improve this question




















  • 1





    Return the slice at the end of the recursion or pass it and assign by reference. When the recursion ends, you are still left with the original slice header you started with, despited the underlying array actually having the data.

    – RayfenWindspear
    Nov 19 '18 at 22:27













  • Sorry ppl, not following completely. Anyone willing to update my code? I'll accept the answer ;)

    – Marcote
    Nov 19 '18 at 22:34
















-1















First of all, this is my first non-dummy program using Go. Any recommendation will be appreciated.



Code description:



I want to retrieve all the information from an API where the information is being paginated. So I want to iterate through all the pages in order to get all the information.



This is what I did so far:



I have the these two functions:



func request(requestData *RequestData) *ProjectsResponse {

client := &http.Client{
Timeout: time.Second * 10,
}

projects := *ProjectsResponse{}
innerRequest(client, requestData.URL, projects)

return projects
}

func innerRequest(client *http.Client, URL string, projects *ProjectsResponse) {

if URL == "" {
return
}

req, err := http.NewRequest("GET", URL, nil)
if err != nil {
log.Printf("Request creation failed with error %sn", err)
}
req.Header.Add("Private-Token", os.Getenv("API_KEY"))

res, err := client.Do(req)
log.Printf("Executing request: %s", req.URL)

if err != nil {
log.Printf("The HTTP request failed with error %sn", err)
}
data, _ := ioutil.ReadAll(res.Body)
var response ProjectsResponse
err = json.Unmarshal(data, &response)

if err != nil {
log.Printf("Unmarshalling failed with error %sn", err)
}

projects = append(projects, &response)
pagingData := getPageInformation(res)
innerRequest(client, pagingData.NextLink, projects)
}


Undesired behavior:



The values in the projects *ProjectsResponse array are being appended on each iteration of the recursion, but when the recursion ends I get an empty array list. So, somehow after the innerRequests ends, in the project variable inside the request method I get nothing.



Hope somebody and spot my mistake.
Thanks in advance.










share|improve this question




















  • 1





    Return the slice at the end of the recursion or pass it and assign by reference. When the recursion ends, you are still left with the original slice header you started with, despited the underlying array actually having the data.

    – RayfenWindspear
    Nov 19 '18 at 22:27













  • Sorry ppl, not following completely. Anyone willing to update my code? I'll accept the answer ;)

    – Marcote
    Nov 19 '18 at 22:34














-1












-1








-1








First of all, this is my first non-dummy program using Go. Any recommendation will be appreciated.



Code description:



I want to retrieve all the information from an API where the information is being paginated. So I want to iterate through all the pages in order to get all the information.



This is what I did so far:



I have the these two functions:



func request(requestData *RequestData) *ProjectsResponse {

client := &http.Client{
Timeout: time.Second * 10,
}

projects := *ProjectsResponse{}
innerRequest(client, requestData.URL, projects)

return projects
}

func innerRequest(client *http.Client, URL string, projects *ProjectsResponse) {

if URL == "" {
return
}

req, err := http.NewRequest("GET", URL, nil)
if err != nil {
log.Printf("Request creation failed with error %sn", err)
}
req.Header.Add("Private-Token", os.Getenv("API_KEY"))

res, err := client.Do(req)
log.Printf("Executing request: %s", req.URL)

if err != nil {
log.Printf("The HTTP request failed with error %sn", err)
}
data, _ := ioutil.ReadAll(res.Body)
var response ProjectsResponse
err = json.Unmarshal(data, &response)

if err != nil {
log.Printf("Unmarshalling failed with error %sn", err)
}

projects = append(projects, &response)
pagingData := getPageInformation(res)
innerRequest(client, pagingData.NextLink, projects)
}


Undesired behavior:



The values in the projects *ProjectsResponse array are being appended on each iteration of the recursion, but when the recursion ends I get an empty array list. So, somehow after the innerRequests ends, in the project variable inside the request method I get nothing.



Hope somebody and spot my mistake.
Thanks in advance.










share|improve this question
















First of all, this is my first non-dummy program using Go. Any recommendation will be appreciated.



Code description:



I want to retrieve all the information from an API where the information is being paginated. So I want to iterate through all the pages in order to get all the information.



This is what I did so far:



I have the these two functions:



func request(requestData *RequestData) *ProjectsResponse {

client := &http.Client{
Timeout: time.Second * 10,
}

projects := *ProjectsResponse{}
innerRequest(client, requestData.URL, projects)

return projects
}

func innerRequest(client *http.Client, URL string, projects *ProjectsResponse) {

if URL == "" {
return
}

req, err := http.NewRequest("GET", URL, nil)
if err != nil {
log.Printf("Request creation failed with error %sn", err)
}
req.Header.Add("Private-Token", os.Getenv("API_KEY"))

res, err := client.Do(req)
log.Printf("Executing request: %s", req.URL)

if err != nil {
log.Printf("The HTTP request failed with error %sn", err)
}
data, _ := ioutil.ReadAll(res.Body)
var response ProjectsResponse
err = json.Unmarshal(data, &response)

if err != nil {
log.Printf("Unmarshalling failed with error %sn", err)
}

projects = append(projects, &response)
pagingData := getPageInformation(res)
innerRequest(client, pagingData.NextLink, projects)
}


Undesired behavior:



The values in the projects *ProjectsResponse array are being appended on each iteration of the recursion, but when the recursion ends I get an empty array list. So, somehow after the innerRequests ends, in the project variable inside the request method I get nothing.



Hope somebody and spot my mistake.
Thanks in advance.







arrays go






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 19 '18 at 22:28







Marcote

















asked Nov 19 '18 at 22:10









MarcoteMarcote

2,21911621




2,21911621








  • 1





    Return the slice at the end of the recursion or pass it and assign by reference. When the recursion ends, you are still left with the original slice header you started with, despited the underlying array actually having the data.

    – RayfenWindspear
    Nov 19 '18 at 22:27













  • Sorry ppl, not following completely. Anyone willing to update my code? I'll accept the answer ;)

    – Marcote
    Nov 19 '18 at 22:34














  • 1





    Return the slice at the end of the recursion or pass it and assign by reference. When the recursion ends, you are still left with the original slice header you started with, despited the underlying array actually having the data.

    – RayfenWindspear
    Nov 19 '18 at 22:27













  • Sorry ppl, not following completely. Anyone willing to update my code? I'll accept the answer ;)

    – Marcote
    Nov 19 '18 at 22:34








1




1





Return the slice at the end of the recursion or pass it and assign by reference. When the recursion ends, you are still left with the original slice header you started with, despited the underlying array actually having the data.

– RayfenWindspear
Nov 19 '18 at 22:27







Return the slice at the end of the recursion or pass it and assign by reference. When the recursion ends, you are still left with the original slice header you started with, despited the underlying array actually having the data.

– RayfenWindspear
Nov 19 '18 at 22:27















Sorry ppl, not following completely. Anyone willing to update my code? I'll accept the answer ;)

– Marcote
Nov 19 '18 at 22:34





Sorry ppl, not following completely. Anyone willing to update my code? I'll accept the answer ;)

– Marcote
Nov 19 '18 at 22:34












2 Answers
2






active

oldest

votes


















1














I'm guessing that all of your project objects are scoped to the function so they no longer exist when the function ends. I don't think you need your projects to exist before you call innerRequest, so you should probably just have that method return the projects. I think something like this should work...



func innerRequest(client *http.Client, URL string) *ProjectsResponse {

if URL == "" {
return nil
}

//More code...

pagingData := getPageInformation(res)
return append(*ProjectsResponse{&response}, innerRequest(client, pagingData.NextLink)...)
}





share|improve this answer































    1














    The confusion lies in the way a slice is handled in Go. Here is the in-depth explanation, but I will abbreviate.



    The common misconception is that the slice you pass around is a reference to the slice, which is false. The actual variable you operate on when you handle a slice is known as a slice header. This is a simple struct with a reference to the underlying array under the covers and follows Go's pass by value rules, i.e. it is copied when passed to a function. Thus, if it is not returned, you won't have the updated header.



    Returning data from recursion follows a straightforward pattern. Here is a basic example. I'm also including a version that doesn't require a return, but operates on the slice as a reference, which will modify the original. (Note: Passing around slice pointers is generally not considered idiomatic Go)



    Playground link: https://play.golang.org/p/v5XeYpH1VlF



    // correct way to return from recursion
    func addReturn(s int) int {
    if finalCondition(s) {
    return s
    }
    s = append(s, 1)
    return addReturn(s)
    }

    // using a reference
    func addReference(s *int) {
    if finalCondition(*s) {
    return
    }
    *s = append(*s, 1)
    addReference(s)
    }

    // whatever terminates the recursion
    func finalCondition(s int) bool {
    if len(s) >= 10 {
    return true
    }
    return false
    }





    share|improve this answer





















    • 1





      After all that, I probably should have just marked it as a duplicate of the many slice header copy issues people have posted...

      – RayfenWindspear
      Nov 19 '18 at 22:53













    • If it's a duplicate, why don't point me to the duplicate question with is answer? It's somewhat pedantic your behavior specially when I'm learning a new language. Empathy -1

      – Marcote
      Nov 20 '18 at 16:30











    • @Marcote Because the duplicate would only explain what is happening with the slice headers, not what is missing from your recursion. Going over both is more useful to you.

      – RayfenWindspear
      Nov 20 '18 at 16:32











    • @Marcote I hadn't noticed the term "pedantic" in your comment until I re-read it just now. Not that I disagree, but one thing you'll find with Go specifically, is that the language itself is minimalistic by design and that the language specification is actually human readable (golang.org/ref/spec) and the documentation is so superb. As a result of this, you'll find many Q/A on SO and many of us answering will seem apathetic at times, and many answers simply refer to the spec or documentation. It's nothing personal, it's just a quirk with the language, and thus its community.

      – RayfenWindspear
      Nov 21 '18 at 19:11











    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53383372%2fproblem-accumulating-appending-values-in-an-array-using-recursion-with-go%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    1














    I'm guessing that all of your project objects are scoped to the function so they no longer exist when the function ends. I don't think you need your projects to exist before you call innerRequest, so you should probably just have that method return the projects. I think something like this should work...



    func innerRequest(client *http.Client, URL string) *ProjectsResponse {

    if URL == "" {
    return nil
    }

    //More code...

    pagingData := getPageInformation(res)
    return append(*ProjectsResponse{&response}, innerRequest(client, pagingData.NextLink)...)
    }





    share|improve this answer




























      1














      I'm guessing that all of your project objects are scoped to the function so they no longer exist when the function ends. I don't think you need your projects to exist before you call innerRequest, so you should probably just have that method return the projects. I think something like this should work...



      func innerRequest(client *http.Client, URL string) *ProjectsResponse {

      if URL == "" {
      return nil
      }

      //More code...

      pagingData := getPageInformation(res)
      return append(*ProjectsResponse{&response}, innerRequest(client, pagingData.NextLink)...)
      }





      share|improve this answer


























        1












        1








        1







        I'm guessing that all of your project objects are scoped to the function so they no longer exist when the function ends. I don't think you need your projects to exist before you call innerRequest, so you should probably just have that method return the projects. I think something like this should work...



        func innerRequest(client *http.Client, URL string) *ProjectsResponse {

        if URL == "" {
        return nil
        }

        //More code...

        pagingData := getPageInformation(res)
        return append(*ProjectsResponse{&response}, innerRequest(client, pagingData.NextLink)...)
        }





        share|improve this answer













        I'm guessing that all of your project objects are scoped to the function so they no longer exist when the function ends. I don't think you need your projects to exist before you call innerRequest, so you should probably just have that method return the projects. I think something like this should work...



        func innerRequest(client *http.Client, URL string) *ProjectsResponse {

        if URL == "" {
        return nil
        }

        //More code...

        pagingData := getPageInformation(res)
        return append(*ProjectsResponse{&response}, innerRequest(client, pagingData.NextLink)...)
        }






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 19 '18 at 23:53









        SlotherooSlotheroo

        36028




        36028

























            1














            The confusion lies in the way a slice is handled in Go. Here is the in-depth explanation, but I will abbreviate.



            The common misconception is that the slice you pass around is a reference to the slice, which is false. The actual variable you operate on when you handle a slice is known as a slice header. This is a simple struct with a reference to the underlying array under the covers and follows Go's pass by value rules, i.e. it is copied when passed to a function. Thus, if it is not returned, you won't have the updated header.



            Returning data from recursion follows a straightforward pattern. Here is a basic example. I'm also including a version that doesn't require a return, but operates on the slice as a reference, which will modify the original. (Note: Passing around slice pointers is generally not considered idiomatic Go)



            Playground link: https://play.golang.org/p/v5XeYpH1VlF



            // correct way to return from recursion
            func addReturn(s int) int {
            if finalCondition(s) {
            return s
            }
            s = append(s, 1)
            return addReturn(s)
            }

            // using a reference
            func addReference(s *int) {
            if finalCondition(*s) {
            return
            }
            *s = append(*s, 1)
            addReference(s)
            }

            // whatever terminates the recursion
            func finalCondition(s int) bool {
            if len(s) >= 10 {
            return true
            }
            return false
            }





            share|improve this answer





















            • 1





              After all that, I probably should have just marked it as a duplicate of the many slice header copy issues people have posted...

              – RayfenWindspear
              Nov 19 '18 at 22:53













            • If it's a duplicate, why don't point me to the duplicate question with is answer? It's somewhat pedantic your behavior specially when I'm learning a new language. Empathy -1

              – Marcote
              Nov 20 '18 at 16:30











            • @Marcote Because the duplicate would only explain what is happening with the slice headers, not what is missing from your recursion. Going over both is more useful to you.

              – RayfenWindspear
              Nov 20 '18 at 16:32











            • @Marcote I hadn't noticed the term "pedantic" in your comment until I re-read it just now. Not that I disagree, but one thing you'll find with Go specifically, is that the language itself is minimalistic by design and that the language specification is actually human readable (golang.org/ref/spec) and the documentation is so superb. As a result of this, you'll find many Q/A on SO and many of us answering will seem apathetic at times, and many answers simply refer to the spec or documentation. It's nothing personal, it's just a quirk with the language, and thus its community.

              – RayfenWindspear
              Nov 21 '18 at 19:11
















            1














            The confusion lies in the way a slice is handled in Go. Here is the in-depth explanation, but I will abbreviate.



            The common misconception is that the slice you pass around is a reference to the slice, which is false. The actual variable you operate on when you handle a slice is known as a slice header. This is a simple struct with a reference to the underlying array under the covers and follows Go's pass by value rules, i.e. it is copied when passed to a function. Thus, if it is not returned, you won't have the updated header.



            Returning data from recursion follows a straightforward pattern. Here is a basic example. I'm also including a version that doesn't require a return, but operates on the slice as a reference, which will modify the original. (Note: Passing around slice pointers is generally not considered idiomatic Go)



            Playground link: https://play.golang.org/p/v5XeYpH1VlF



            // correct way to return from recursion
            func addReturn(s int) int {
            if finalCondition(s) {
            return s
            }
            s = append(s, 1)
            return addReturn(s)
            }

            // using a reference
            func addReference(s *int) {
            if finalCondition(*s) {
            return
            }
            *s = append(*s, 1)
            addReference(s)
            }

            // whatever terminates the recursion
            func finalCondition(s int) bool {
            if len(s) >= 10 {
            return true
            }
            return false
            }





            share|improve this answer





















            • 1





              After all that, I probably should have just marked it as a duplicate of the many slice header copy issues people have posted...

              – RayfenWindspear
              Nov 19 '18 at 22:53













            • If it's a duplicate, why don't point me to the duplicate question with is answer? It's somewhat pedantic your behavior specially when I'm learning a new language. Empathy -1

              – Marcote
              Nov 20 '18 at 16:30











            • @Marcote Because the duplicate would only explain what is happening with the slice headers, not what is missing from your recursion. Going over both is more useful to you.

              – RayfenWindspear
              Nov 20 '18 at 16:32











            • @Marcote I hadn't noticed the term "pedantic" in your comment until I re-read it just now. Not that I disagree, but one thing you'll find with Go specifically, is that the language itself is minimalistic by design and that the language specification is actually human readable (golang.org/ref/spec) and the documentation is so superb. As a result of this, you'll find many Q/A on SO and many of us answering will seem apathetic at times, and many answers simply refer to the spec or documentation. It's nothing personal, it's just a quirk with the language, and thus its community.

              – RayfenWindspear
              Nov 21 '18 at 19:11














            1












            1








            1







            The confusion lies in the way a slice is handled in Go. Here is the in-depth explanation, but I will abbreviate.



            The common misconception is that the slice you pass around is a reference to the slice, which is false. The actual variable you operate on when you handle a slice is known as a slice header. This is a simple struct with a reference to the underlying array under the covers and follows Go's pass by value rules, i.e. it is copied when passed to a function. Thus, if it is not returned, you won't have the updated header.



            Returning data from recursion follows a straightforward pattern. Here is a basic example. I'm also including a version that doesn't require a return, but operates on the slice as a reference, which will modify the original. (Note: Passing around slice pointers is generally not considered idiomatic Go)



            Playground link: https://play.golang.org/p/v5XeYpH1VlF



            // correct way to return from recursion
            func addReturn(s int) int {
            if finalCondition(s) {
            return s
            }
            s = append(s, 1)
            return addReturn(s)
            }

            // using a reference
            func addReference(s *int) {
            if finalCondition(*s) {
            return
            }
            *s = append(*s, 1)
            addReference(s)
            }

            // whatever terminates the recursion
            func finalCondition(s int) bool {
            if len(s) >= 10 {
            return true
            }
            return false
            }





            share|improve this answer















            The confusion lies in the way a slice is handled in Go. Here is the in-depth explanation, but I will abbreviate.



            The common misconception is that the slice you pass around is a reference to the slice, which is false. The actual variable you operate on when you handle a slice is known as a slice header. This is a simple struct with a reference to the underlying array under the covers and follows Go's pass by value rules, i.e. it is copied when passed to a function. Thus, if it is not returned, you won't have the updated header.



            Returning data from recursion follows a straightforward pattern. Here is a basic example. I'm also including a version that doesn't require a return, but operates on the slice as a reference, which will modify the original. (Note: Passing around slice pointers is generally not considered idiomatic Go)



            Playground link: https://play.golang.org/p/v5XeYpH1VlF



            // correct way to return from recursion
            func addReturn(s int) int {
            if finalCondition(s) {
            return s
            }
            s = append(s, 1)
            return addReturn(s)
            }

            // using a reference
            func addReference(s *int) {
            if finalCondition(*s) {
            return
            }
            *s = append(*s, 1)
            addReference(s)
            }

            // whatever terminates the recursion
            func finalCondition(s int) bool {
            if len(s) >= 10 {
            return true
            }
            return false
            }






            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Nov 19 '18 at 23:26

























            answered Nov 19 '18 at 22:38









            RayfenWindspearRayfenWindspear

            3,7131329




            3,7131329








            • 1





              After all that, I probably should have just marked it as a duplicate of the many slice header copy issues people have posted...

              – RayfenWindspear
              Nov 19 '18 at 22:53













            • If it's a duplicate, why don't point me to the duplicate question with is answer? It's somewhat pedantic your behavior specially when I'm learning a new language. Empathy -1

              – Marcote
              Nov 20 '18 at 16:30











            • @Marcote Because the duplicate would only explain what is happening with the slice headers, not what is missing from your recursion. Going over both is more useful to you.

              – RayfenWindspear
              Nov 20 '18 at 16:32











            • @Marcote I hadn't noticed the term "pedantic" in your comment until I re-read it just now. Not that I disagree, but one thing you'll find with Go specifically, is that the language itself is minimalistic by design and that the language specification is actually human readable (golang.org/ref/spec) and the documentation is so superb. As a result of this, you'll find many Q/A on SO and many of us answering will seem apathetic at times, and many answers simply refer to the spec or documentation. It's nothing personal, it's just a quirk with the language, and thus its community.

              – RayfenWindspear
              Nov 21 '18 at 19:11














            • 1





              After all that, I probably should have just marked it as a duplicate of the many slice header copy issues people have posted...

              – RayfenWindspear
              Nov 19 '18 at 22:53













            • If it's a duplicate, why don't point me to the duplicate question with is answer? It's somewhat pedantic your behavior specially when I'm learning a new language. Empathy -1

              – Marcote
              Nov 20 '18 at 16:30











            • @Marcote Because the duplicate would only explain what is happening with the slice headers, not what is missing from your recursion. Going over both is more useful to you.

              – RayfenWindspear
              Nov 20 '18 at 16:32











            • @Marcote I hadn't noticed the term "pedantic" in your comment until I re-read it just now. Not that I disagree, but one thing you'll find with Go specifically, is that the language itself is minimalistic by design and that the language specification is actually human readable (golang.org/ref/spec) and the documentation is so superb. As a result of this, you'll find many Q/A on SO and many of us answering will seem apathetic at times, and many answers simply refer to the spec or documentation. It's nothing personal, it's just a quirk with the language, and thus its community.

              – RayfenWindspear
              Nov 21 '18 at 19:11








            1




            1





            After all that, I probably should have just marked it as a duplicate of the many slice header copy issues people have posted...

            – RayfenWindspear
            Nov 19 '18 at 22:53







            After all that, I probably should have just marked it as a duplicate of the many slice header copy issues people have posted...

            – RayfenWindspear
            Nov 19 '18 at 22:53















            If it's a duplicate, why don't point me to the duplicate question with is answer? It's somewhat pedantic your behavior specially when I'm learning a new language. Empathy -1

            – Marcote
            Nov 20 '18 at 16:30





            If it's a duplicate, why don't point me to the duplicate question with is answer? It's somewhat pedantic your behavior specially when I'm learning a new language. Empathy -1

            – Marcote
            Nov 20 '18 at 16:30













            @Marcote Because the duplicate would only explain what is happening with the slice headers, not what is missing from your recursion. Going over both is more useful to you.

            – RayfenWindspear
            Nov 20 '18 at 16:32





            @Marcote Because the duplicate would only explain what is happening with the slice headers, not what is missing from your recursion. Going over both is more useful to you.

            – RayfenWindspear
            Nov 20 '18 at 16:32













            @Marcote I hadn't noticed the term "pedantic" in your comment until I re-read it just now. Not that I disagree, but one thing you'll find with Go specifically, is that the language itself is minimalistic by design and that the language specification is actually human readable (golang.org/ref/spec) and the documentation is so superb. As a result of this, you'll find many Q/A on SO and many of us answering will seem apathetic at times, and many answers simply refer to the spec or documentation. It's nothing personal, it's just a quirk with the language, and thus its community.

            – RayfenWindspear
            Nov 21 '18 at 19:11





            @Marcote I hadn't noticed the term "pedantic" in your comment until I re-read it just now. Not that I disagree, but one thing you'll find with Go specifically, is that the language itself is minimalistic by design and that the language specification is actually human readable (golang.org/ref/spec) and the documentation is so superb. As a result of this, you'll find many Q/A on SO and many of us answering will seem apathetic at times, and many answers simply refer to the spec or documentation. It's nothing personal, it's just a quirk with the language, and thus its community.

            – RayfenWindspear
            Nov 21 '18 at 19:11


















            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53383372%2fproblem-accumulating-appending-values-in-an-array-using-recursion-with-go%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Guess what letter conforming each word

            Port of Spain

            Run scheduled task as local user group (not BUILTIN)