Problem accumulating/appending values in an array using recursion with Go
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
add a comment |
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
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
add a comment |
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
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
arrays go
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
add a comment |
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
add a comment |
2 Answers
2
active
oldest
votes
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)...)
}
add a comment |
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
}
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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)...)
}
add a comment |
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)...)
}
add a comment |
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)...)
}
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)...)
}
answered Nov 19 '18 at 23:53
SlotherooSlotheroo
36028
36028
add a comment |
add a comment |
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
}
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
add a comment |
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
}
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
add a comment |
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
}
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
}
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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