[go-nuts] Re: Interface ????
Because then you could do this:
func PrintAll(vals []interface{}) {
vals[0] = 123
}
func main() {
names := []string{"stanley", "david", "oscar"}
var s string
s = names[0]
}
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Ternary ... again
color := colorFor(temperature)
func colorFor(temperature int) string {
if temperature > 100 {
return "red"
}
return "blue"
}
On Thursday, 16 August 2018 18:01:20 UTC+2, Haddock wrote:
>
>
> var color
>> if temperature > 100 {
>> color = “red”
>> } else {
>> color = “blue”
>> }
>>
>
> IMHO, it could be argued about whether adding something like this would be
> useful:
>
> color := if temperature > 100 {
> return “red”
> } else {
> return “blue”
> }
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] What's the status of the new Go brand?
The announcement in April said: What’s happening next > > The website will be getting a refresh based on the new design. Since we > are making significant changes, we are also taking this opportunity to > update our website infrastructure to better serve our global community with > internationalization and multilingual support. The migration will happen in > stages over the next few months starting with this blog. https://blog.golang.org/go-brand A few months have passed, yet nothing has changed. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Link: Getting specific about generics
I prefer seeing the contract by example over having a combination of two
dozens of interface names like Eq, Lesser, Adder, Muler, Convertible(x),
Ranger, Lener, Caper, ... that have to be mentally mapped to their actual
syntactic representation. This smells like taxonomy ("the lowest form of
academic work" ;)
On Sunday, 2 September 2018 10:14:48 UTC+2, Tristan Colgate wrote:
>
> It's a great read, clarified stuff for me. An approach that embraces
> interfaces feels preferable to me.
>
>
> On Sun, 2 Sep 2018, 09:09 'Charlton Trezevant' via golang-nuts, <
> golan...@googlegroups.com > wrote:
>
>> Link: [Getting specific about generics, by Emily Maier](
>> https://emilymaier.net/words/getting-specific-about-generics/)
>>
>> The interface-based alternative to contracts seems like such a natural
>> fit- It’s simple, straightforward, and pragmatic. I value those aspects of
>> Go’s philosophy and consider them to be features of the language, so it’s
>> encouraging to see a solution that suits them so well. The author also does
>> a great job of contextualizing the use cases and debate around generics,
>> which I found incredibly helpful.
>>
>> Any thoughts?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Error checking in Go: The `try` keyword
The original, rejected proposal was better because it was a built-in, not a new keyword, so it didn't break existing tools. Otherwise I don't see a difference. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9ef98c66-b6c4-46dd-af76-92a26f97eb64%40googlegroups.com.
[go-nuts] Re: RFC Package structuring
1 go.{mod|sum} per repository, no vendoring
tree/
angular-ui/
cmd/
hello-api-server/
hello-cli/
hello-daemon/
internal/
internal-lib1/
internal-lib2/
library1/
library2/
library3/
python-tests/
go.mod
go.sum
On Saturday, 29 February 2020 19:03:34 UTC+1, Sankar wrote:
>
> I am starting a new project (say `hello`) and I am totally confused about
> what package structure to use.
>
> I am going to go with a monolithic source repository which would be
> checked out under `~/src` directory in the developer machines.
>
> I have three golang binaries available in my project.
>
> 1) hello-cli : A tool that would give me a CLI, which will be used from my
> client machines. Say something similar to the docker-cli
> 2) hello-daemon: A daemon to which the CLI tools will talk to. Say
> something similar to docker-daemon
> 3) hello-api-server: A HTTP server to which the daemon will talk. Say
> something similar to dockerhub API server.
>
> In addition to these three golang binaries, I may have other things like a
> webui, some static assets, some integration tests etc. in multiple
> languages.
>
> There will be some libraries that will be used by each of the golang
> binaries that will be internal only to the specific binaries and there will
> be some libraries, which will be shared across the three binaries. The
> three binaries may depend on different versions of the libraries.
>
> Now the package structure that I thought was:
>
> [image: Screenshot 2020-02-29 at 11.28.45 PM.png]
>
> Will this be good or should I make any change ? I am not sure if vendoring
> would work fine here as there would be no `github.com/`
>
[go-nuts] Re: [Generics] Concise generics with package level types
Why not put type parameters on packages? https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-put-type-parameters-on-packages -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/04de6b16-f030-45b6-a64d-61401a9566afo%40googlegroups.com.
[go-nuts] Re: [generics] Use decorators ($, or @, or #) to specify that the type is a generic type.
On Thursday, 25 June 2020 06:17:24 UTC+2, Andrey T. wrote:
> 3. Ability to use decorated interface name as spec for type constrains
>
>func (type T Comparable) Max(a... T) (result T) {...}
>
>might become
>
>func Max(a... $Comparable) (result $Comparable) {...}
>
I don't see how this is equivalent. The point of the T constraint is that
both T are the *same* Comparable type and not just any two Comparables.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/dedaacad-7cd9-476b-b473-5ccc931b1f9co%40googlegroups.com.
