Altera em 1 instância apenas 👍

Verdade. Até desenhando fica complicado. Quando acha que entendeu, alguma coisa dá errado. hauahuahuah

Não é nada sujo, isso é bem prático na verdade, principalmente quando utilizamos funções recursivas onde se manipula os valores de uma ou mais variáveis, vc evita ter que ficar atribuindo o valor manipulado sempre de volta pra variável, sendo que recursivamente vc poderia nem ter chego ao trecho do código onde a variável é atribuída, gerando um "problema" de ter que ficar devolvendo o valor recursivamente. Na questão de mudar de qualquer lugar, vc não tá mudando de qualquer lugar, vc está explicitamente chamando uma função que tem sua assinatura o recebimento de ponteiro, logo vc sabe o que está acontecendo ali.

Não é porque você usa ponteiros que nunca usará return. Um bom exemplo disso é o uso de "encoding/json". Por exemplo: func (a *Authentication) toObject(data []byte) error { return json.Unmarshal(data, a) } var credencial Authentication err := credencial.toObject(jsonData) Apenas não compreendi ao certo o que quis dizer com "funções sujas", se foi para expressar complexidade por efeitos colaterais (side-effects), você tem razão. Dessa forma, é crucial ter cautela ao usar o ponteiro, pois, se usado inadequadamente, pode resultar em código de difícil compreensão e manutenção, uma vez que pode ser difícil acompanhar onde e quando o estado está sendo alterado.

Entendo que a pergunta foi há um ano, mas responderei da maneira mais curta e elucidativa possível: Em Go, os parâmetros recebem os valores em cópia. Isso quer dizer que: a := 10 add(a, 1) // soma "a" + 1 A variável "a" foi passado por valor (aka. Pass by Value). Outra expressão que denota o mesmo conceito e esclarece ainda mais a ocorrência, é o termo "Pass by Copy", que diz que o "valor de 'a' foi passado em cópia" para a função "add". Ou seja: a := 10 fmt.Println(add(a, 1)) // imprimirá 11 fmt.Println(a) // imprimirá 10 Isso acontece porque "a" não foi alterado, o que foi alterado é a cópia dele que residiu no escopo da função "add" e quando ela retorna (ou seja, acaba), os valores do escopo dela são descartadas. Para efetuar uma mudança em "a" e não em sua cópia, é preciso utilizar o ponteiro. Ficando desta forma: a := 10 add(&a, 1) Em outros cenários que se usa estruturas, a visualização do código muda um pouco, mas o conceito permanece: a := Soma{ operando: 10 } func (s *Soma) add(valor int) { s.operando += valor } a.Soma(1) O uso de "*Soma" faz com que o valor da estrutura instanciada em "a" seja alterada. Você pode até usar "Som" (sem o asterisco - neste caso, sem o ponteiro), mas o efeito não satisfará porque "a.operando" somente será 11 durante a execução do método "add()"; como falei antes, assim que ele terminar sua execução, o valor será descartado e "a" voltará para o valor original, o estado que era antes do "add" ser chamado. Tentei explicar a diferença entre o efeito de "Pass by Value" (esse mesmo termo é chamado também de "Pass by Copy") e o "Pass by Reference".

Gostaria de complementar com uma coisa: Em Go, não existe Pass by Reference como existe em C, C++, Java, etc. A explicação que fiz acima sobre o efeito de modificação do valor original, a linguagem Go ainda utiliza o conceito "Pass by Value" para dar efeito "Pass by Reference". Quando você passa um ponteiro para uma função em Go, a função ainda recebe uma cópia do ponteiro. Isso significa que é criado um novo ponteiro que aponta para o mesmo local de memória da variável original. Portanto, ao modificar o valor ao qual o ponteiro aponta, as alterações serão refletidas na variável original porque ambos os ponteiros (o original e a cópia) apontam para o mesmo local de memória. Outras terminologias que o pessoal costuma utilizar é chamar de "valor direto" para referir-se ao "endereço de memória" da variável: a := 10 fmt.Println(&a) // imprimira um valor hexadecimal, algo como 0xc0000160a0 (foi demonstrado no vídeo em 6:58). O valor "0xc0000160a0" é o valor direto. Também existe o termo "valor indireto" que é o valor que o ponteiro aponta, neste caso, do exemplo, é o inteiro 10.

@@luciusstark Excelente explicação amigo. Apenas fazendo uma analogia, seria como trabalhar como uma linguagem orientada a objetos, fazendo uso do THIS. Eu posso ter uma variável no scopo da minha classe, e outra variavel com o mesmo nome dentro de um método. O que tornaria os valores diferentes em ambas as variáveis, seria a utilização do THIS, para acessar a variável declarada no scopo da classe.

É que nesse exemplo parece ser inútil usar ponteiro pois ele quis mais explicar o conceito. Mas se vc importa um pacote que tem um tipo de função que recebe um valor externo e retorna uma variável, o ponteiro é interessante para fazer a substituição e deixar o código mais clean tb

Sim, o uso de ponteiros é para fins de desempenho e modificação no valor original e não em sua cópia. No caso da função Carro, você está correto. Porém, entende-se que a prova de conceito apresentado neste vídeo serve somente para entender o funcionamento do ponteiro e não a sua utilidade. O uso de ponteiros ou valores ainda é comumente confuso para uma certa porção de desenvolvedores. Em geral, usar os ponteiros é útil quando você quer modificar o valor original, evitar cópias desnecessárias de dados imensos ou implementar estruturas de dados dinâmicas como listas encadeadas ou árvores. Usar valores é preferível quando você quer evitar efeitos colaterais, trabalhar com tipos simples ou pequenos, ou garantir a imutabilidade dos dados. Muitos são educados que a linguagem Go usa o conceito "Pass by Value" e quando estuda sobre ponteiros, acham que outro conceito é usado; sendo que, na verdade, Go ainda utiliza "Pass by Value" para dar efeito de "Pass by Reference". Acontece que a cópia do argumento é o endereço de memória (&var) e não o valor em si (*var), por ser cópia, você tem dois ponteiros que apontam para o mesmo valor. Ou seja, é melhor você ter uma cópia de endereçamento de memória que aponta para um dado imenso do que copiar esses dados.