[go-nuts] Is there a compiler options to detect and disable unsafe uses in third-party packages?

[T L]

.

-- 
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/dad846f9-a631-461a-93a0-a87a19811677%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Go 1.8 port to FreeBSD/PowerPC64

[Curtis Hamilton]

I’m porting Go 1.8 to FreeBSD/PowerPC64.  I’ve successfully built 
go-FreeBSD-ppc64-bootstrap using go on FreeBSD/amd64.

However, l’m getting the error go: cannot find GOROOT directory, when executing 
‘go env’ on the target system.

I’m not sure if this is a code issue.  I’ve tried some of the tips about 
setting GOROOT and GOPATH, with no success.

Can someone help?

-- 
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/82c09915-147f-49cd-8860-cfafda7df837%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Announcing NSWrap -- a comprehensive Objective-C binding generator for MacOS

[Greg Pomerantz]

I see. No, that is not how it works, the user needs to manually handle 
memory management for all Objective-C objects, calling Release() on objects 
that are manually allocated and no longer used, and calling Retain() to 
take ownership of objects that need to be kept. In many contexts (e.g. 
NSApplication callbacks), the Objective-C runtime provides an autorelease 
pool, so there will not need to be too much manual memory management -- 
object constructors provided by the binding automatically call 
"autorelease" before returning pointers to Go, so any temporary objects 
created during a callback should be freed automatically without any need to 
call Retain() or Release().

That said none of this has been thoroughly tested and I'm not entirely sure 
what a good test environment would look like for something like this. If 
you want to see what happens if you do it wrong, you can at least comment 
out the "Retain" calls in the examples and watch them crash.

On Friday, May 31, 2019 at 9:15:41 PM UTC-4, robert engels wrote:
>
> What I meant was that the refs should be treated like any Go object 
> instance, and when collected on the Go side it should dec the ref count so 
> the object can be freed on the OSX side.
>
> Might be tricky with weak refs, etc.
>
> Is that what happens?
>
> On May 31, 2019, at 11:33 AM, Greg Pomerantz > 
> wrote:
>
> Also I don't think an API is going to assume or require ARC -- as far as I 
> understand it, ARC is just a compiler shortcut that adds retain and release 
> calls so the programmer doesn't have to, it is not any sort of runtime 
> memory management or garbage collection system. As long as Clang has a 
> -fno-objc-arc flag, there should be no problem turning ARC off.
>
> On Friday, May 31, 2019 at 11:51:01 AM UTC-4, Robert Engels wrote:
>>
>> Isn't a lack of ARC support a critical limitation, as ARC is required 
>> going forward, and many of the newer API's assume ARC behind the scenes?
>>
>> -Original Message- 
>> From: Greg Pomerantz 
>> Sent: May 30, 2019 8:25 AM 
>> To: golang-nuts 
>> Subject: [go-nuts] Announcing NSWrap -- a comprehensive Objective-C 
>> binding generator for MacOS 
>>
>> I have been working on a binding generator that can read MacOS header 
>> files and provide bindings for Objective-C interfaces and library 
>> functions. NSWrap can also automatically generate classes implementing one 
>> or more named protocols or subclassing a specified class.
>>
>> The automatically generated Go types implement method inheritance, and 
>> overloaded method names are disambiguated. Variadic functions and methods 
>> are supported and pointers to pointers are converted into slices. You can 
>> create selectors (to assign actions to NSControl objects, for example) and 
>> access Objective-C memory management methods (other than Automatic 
>> Reference Counting), including AutoreleasePools.
>>
>> An example Cocoa application is provided in 24 lines of Go code. A 
>> text-mode Bluetooth Low Energy heart rate monitor in pure Go is 127 lines. 
>> The official git repository is linked below. This is the first release, so 
>> expect plenty of rough edges.
>>
>> https://git.wow.st/gmp/nswrap
>>
>> -- 
>> 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 golan...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/15be0140-b994-4692-9062-4792be74a8f9%40googlegroups.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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/5ff1a68f-c379-4ea7-9177-1a4e15f899a9%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/29b141d8-b41f-4f5f-bfb2-9761fef4591d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Announcing NSWrap -- a comprehensive Objective-C binding generator for MacOS

[robert engels]

What I meant was that the refs should be treated like any Go object instance, 
and when collected on the Go side it should dec the ref count so the object can 
be freed on the OSX side.

Might be tricky with weak refs, etc.

Is that what happens?

> On May 31, 2019, at 11:33 AM, Greg Pomerantz  wrote:
> 
> Also I don't think an API is going to assume or require ARC -- as far as I 
> understand it, ARC is just a compiler shortcut that adds retain and release 
> calls so the programmer doesn't have to, it is not any sort of runtime memory 
> management or garbage collection system. As long as Clang has a -fno-objc-arc 
> flag, there should be no problem turning ARC off.
> 
> On Friday, May 31, 2019 at 11:51:01 AM UTC-4, Robert Engels wrote:
> Isn't a lack of ARC support a critical limitation, as ARC is required going 
> forward, and many of the newer API's assume ARC behind the scenes?
> 
> -Original Message- 
> From: Greg Pomerantz 
> Sent: May 30, 2019 8:25 AM 
> To: golang-nuts 
> Subject: [go-nuts] Announcing NSWrap -- a comprehensive Objective-C binding 
> generator for MacOS 
> 
> I have been working on a binding generator that can read MacOS header files 
> and provide bindings for Objective-C interfaces and library functions. NSWrap 
> can also automatically generate classes implementing one or more named 
> protocols or subclassing a specified class.
> 
> The automatically generated Go types implement method inheritance, and 
> overloaded method names are disambiguated. Variadic functions and methods are 
> supported and pointers to pointers are converted into slices. You can create 
> selectors (to assign actions to NSControl objects, for example) and access 
> Objective-C memory management methods (other than Automatic Reference 
> Counting), including AutoreleasePools.
> 
> An example Cocoa application is provided in 24 lines of Go code. A text-mode 
> Bluetooth Low Energy heart rate monitor in pure Go is 127 lines. The official 
> git repository is linked below. This is the first release, so expect plenty 
> of rough edges.
> 
> https://git.wow.st/gmp/nswrap 
> 
> -- 
> 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 golan...@ <>googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/15be0140-b994-4692-9062-4792be74a8f9%40googlegroups.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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/5ff1a68f-c379-4ea7-9177-1a4e15f899a9%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/55E4EC25-2107-4273-B52A-E474680CFE79%40ix.netcom.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] go version go1.12 and cannot find module providing package

['Bryan Mills' via golang-nuts]

The highest release tag on that module is v0.0.2, and that version indeed does 
not provide the clis package.

If you want a commit that is more recent than the latest release, you need to 
request that commit to 'go get' explicitly.

-- 
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/4933c5b1-8f36-4932-8a63-c4ee372e77b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go package manager

[Justin Israel]

On Saturday, June 1, 2019 at 12:43:50 AM UTC+12, yashi...@gmail.com wrote:
> Hi everyone!
> 
> I recently build an interesting Go tool - GPM (Go Project Manager). It allows 
> you to build and manage go projects. Ont op, it also allows to update version 
> of Go from cli.
> Check it out: https://github.com/YashishDua/gpm
> 
> Feedback is appreciated!

Your README doesn't indicate that it only supports OSX. The "update" command 
downloads the osx build and replaces a hard-coded system install location.

Aside from the "create" command setting up an opinionated project structure, to 
me is seems like the build, mod, vendor logic just thinly wraps calls to the Go 
tool equivalent commands. What is it really doing that the current go tool 
doesn't handle? I thought go module support works in any location already. 

-- 
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/4ce39173-697a-408a-9a2d-92d84f7b7468%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

[Randall O'Reilly]

This seems similar to previous proposals based on introducing kind-based type 
categories for contracts.  Putting the kind right there in the arg instead of a 
separate contract seems like an improvement, keeping it more local to where it 
is used.  Why not just take this one step further and just introduce entirely 
new types:

* number
* slice
* map (re-useable from existing use-case?)
* etc

func Min(x, y number) number {
   if x < y {
  return x
   }
   return y
}

func Delete(sl *slice, idx int) {
   *sl = append((*sl)[:idx], (*sl)[idx+1:])
}

The compiler would just do its normal thing based on whatever actual kind you 
pass in — an implicit type switch basically..

You could convert any `number` into a specific type (e.g., float64) when you 
need to, and if you passed two different underlying types of numbers as args to 
Min, it would automatically up-convert to the one with highest precision.  
Essentially, this is undoing all the strict type specificity of Go, and making 
it work like C, or Python..

This minimalist approach avoids all the complexity and ugliness of 
parameterizing types etc — it is just a more generic type of type, and is more 
or less how the generic builtin operators and functions like len, copy, etc 
already work on their respective kinds.

Composite types seem like they might even just work without a type parameter:

type Vec2 struct {
   X, Y number
}

func (u Vec2) Add(v Vec2) Vec2 {
   return Vec2{u.X + v.X, u.Y + u.Y}
}

In summary, this is really just introducing a very controlled dose of dynamic 
typing into the language (adding a dash of Python into Go).  Probably this has 
already been considered and rejected hundreds of times over the course of these 
discussions, but I’ve lost track, and seems at least like a very simple 
conceptual proposal: you can achieve a lot of generics functionality by just 
introducing dynamic typing.  Syntactically and conceptually, it is far cleaner 
and simpler than anything else I’ve seen in the generics discussion, at least.

- Randy

> On May 31, 2019, at 6:52 AM, Michal Strba  wrote:
> 
> @Ian, I have been thinking and I’ve come up with a possible solution to yours 
> and some other problems. I’d love to hear your thoughts on it. Note, that 
> this is a very fresh idea.
> 
> I’m addressing two problems here:
> 
>   • Inability to do Min/Max and other generic numeric functions.
>   • There are a few kinds of generic parameters, but the kind is always 
> implicit. This can be a problem because changing the body of a function can 
> result in a backward-incompatible change, even when the signature remains the 
> same.
> Here are the ideas (also described in the proposal now, in the section called 
> ‘Further ideas’).
> 
> The kind of a generic parameters is currently completely implicit. Some 
> annotation could be added. One possible syntax could be like this:
> 
>   • gen n for generic array lengths.
>   • gen T for arbitrary types (convertible to interface{}).
>   • gen eq T for equalable types (comparable with == and usable as map 
> keys).
>   • gen num T for numeric types (with operators like +, -, <, …).
> Array lengths and arbitrary types can have the same notation because it’s 
> always possible to distinguish them by context. Alternatively, they could be 
> distinguished by capitalization (lower-case for array lengths, upper-case for 
> types).
> 
> Syntax-wise, eq and num would not be keywords on their own. Rather, gen eq 
> and gen num would be two-word keywords.
> 
> The syntax is rather ad-hoc, I admit. It’s a very fresh idea, completely open 
> to refinement. However, since there are only four cases, an ad-hoc syntax may 
> actually be the right choice.
> 
> It’s also easily extensible with new possible “contracts”, but I’d generally 
> advise against that.
> 
> The addition of the num restriction would actually enable many cool things. 
> First, the Min/Max functions:
> 
> func
>  Min(x, y gen num T) T {
> 
> if
>  x < y {
> 
> return
>  x
> }
> 
> return
>  y
> }
> 
> It would also be useful for generic math types, like vector and matrices. The 
> matrix example above uses float64, but it could be generalized to all numeric 
> types.
> 
> As an example, let’s take a look at a possible implementation of a 2D vector 
> type:
> 
> type Vec2(T) struct
>  {
> X, Y T
> }
> 
> There are no restrictions specified in the type definition. This is because 
> it’s methods and functions that require restrictions, not the types 
> themselves. For example, this String method requires no restrictions:
> 
> func (u Vec2(gen T)) String() string
>  {
> 
> return fmt.Sprintf("(%v, %v)"
> , u.X, u.Y)
> }
> 
> This Eq method requires the types to be comparable with ==:
> 
> func (u Vec2(gen eq T)) Eq(v Vec2(T)) bool
>  {
> 
> return
>  u.X == v.X && u.Y == v.Y
> }
> 
> But, this Add method requires the types to be numeric:
> 
> func
>  (u Vec2(gen num T)) Add(v Vec2(T)) Vec2(T) {
>  

[go-nuts] Re: Go Module Mirror and Checksum Database in Beta!

[Amnon Baron Cohen]

Not really. 
You need the list feature of GOPROXY, which is only available in 1.13 (or 
tip).


>
> Is there a way to test proxy.golang.org with go1.12 if we have private 
> dependencies ? 
>
> -- 
> William Dodé 
>
>

-- 
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/c0240271-d1f3-43d7-a12f-0fc772ded6b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Module Mirror and Checksum Database in Beta!

[Katie Hockman]

Thanks for the feedback! There is an issue tracking this here:
https://github.com/golang/go/issues/32343

On Fri, May 31, 2019, 3:17 PM Jim Ancona  wrote:

>
>
> On Thu, May 30, 2019 at 5:14 PM Katie Hockman  wrote:
>
>> Our privacy policy explains how we collect and use your information. The
>> privacy policy for all of these services is proxy.golang.org/privacy.
>>
>
> I tried visiting that page, which redirected to
> https://policies.google.com/privacy Unfortunately that page doesn't
> really help me to understand what data you will collect from
> proxy.golang.org or sum.golang.org and how you might use it. Is there a
> clear and simple explanation of that available? If no, perhaps there should
> be.
>
> Thanks!
>
>

-- 
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/CALvTBvc-CxCjsjwtSOMBA-JuyBZo_Ju%2BCbur5TyJmB1gNu5Buw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] 【Go Specification fix proposal】about ConstSpec = IdentifierList [ [ Type ] "=" ExpressionList ] .

[Jan Mercl]

On Fri, May 31, 2019 at 9:52 PM  wrote:

> because const declaration cannot omit value.

https://play.golang.org/p/gLlHpdpniTg

-- 
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/CAA40n-WX4Qm9XbvF3YmGHK__ahU6WgMvo%3DfH2kP-LrXhh60m0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] 【Go Specification fix proposal】about ConstSpec = IdentifierList [ [ Type ] "=" ExpressionList ] .

[k . kubo . private . mobile]

In Go Language Specification, I saw the definition of const.
https://golang.org/ref/spec#Constant_declarations


ConstDecl  = "const" ( ConstSpec  | 
"(" { ConstSpec  ";" } ")" ) .ConstSpec  
= IdentifierList  [ [ Type 
 ] "=" ExpressionList 
 ] .

I think, second line might be

ConstSpec  = IdentifierList  [ 
Type  ] "=" ExpressionList 
 .

because const declaration cannot omit value.

-- 
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/4329ad70-c3a2-4021-918a-04b080ac2154%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Module Mirror and Checksum Database in Beta!

[Jim Ancona]

On Thu, May 30, 2019 at 5:14 PM Katie Hockman  wrote:

> Our privacy policy explains how we collect and use your information. The
> privacy policy for all of these services is proxy.golang.org/privacy.
>

I tried visiting that page, which redirected to
https://policies.google.com/privacy Unfortunately that page doesn't really
help me to understand what data you will collect from proxy.golang.org or
sum.golang.org and how you might use it. Is there a clear and simple
explanation of that available? If no, perhaps there should be.

Thanks!

-- 
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/CAKYY9A%2B02Czwy8xrd7bUW%2BNTYgvFHS-ogHR1r%3D9b1wx2CNpzZw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Announcing NSWrap -- a comprehensive Objective-C binding generator for MacOS

[Michael Jones]

This is impressive. Thank you.

On Fri, May 31, 2019 at 9:33 AM Greg Pomerantz  wrote:

> Also I don't think an API is going to assume or require ARC -- as far as I
> understand it, ARC is just a compiler shortcut that adds retain and release
> calls so the programmer doesn't have to, it is not any sort of runtime
> memory management or garbage collection system. As long as Clang has a
> -fno-objc-arc flag, there should be no problem turning ARC off.
>
> On Friday, May 31, 2019 at 11:51:01 AM UTC-4, Robert Engels wrote:
>>
>> Isn't a lack of ARC support a critical limitation, as ARC is required
>> going forward, and many of the newer API's assume ARC behind the scenes?
>>
>> -Original Message-
>> From: Greg Pomerantz
>> Sent: May 30, 2019 8:25 AM
>> To: golang-nuts
>> Subject: [go-nuts] Announcing NSWrap -- a comprehensive Objective-C
>> binding generator for MacOS
>>
>> I have been working on a binding generator that can read MacOS header
>> files and provide bindings for Objective-C interfaces and library
>> functions. NSWrap can also automatically generate classes implementing one
>> or more named protocols or subclassing a specified class.
>>
>> The automatically generated Go types implement method inheritance, and
>> overloaded method names are disambiguated. Variadic functions and methods
>> are supported and pointers to pointers are converted into slices. You can
>> create selectors (to assign actions to NSControl objects, for example) and
>> access Objective-C memory management methods (other than Automatic
>> Reference Counting), including AutoreleasePools.
>>
>> An example Cocoa application is provided in 24 lines of Go code. A
>> text-mode Bluetooth Low Energy heart rate monitor in pure Go is 127 lines.
>> The official git repository is linked below. This is the first release, so
>> expect plenty of rough edges.
>>
>> https://git.wow.st/gmp/nswrap
>>
>> --
>> 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 golan...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/15be0140-b994-4692-9062-4792be74a8f9%40googlegroups.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/5ff1a68f-c379-4ea7-9177-1a4e15f899a9%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
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/CALoEmQzf-SEiA6-NxsxjXkQE-ws%3DJgnXADh0FNLSwcsLt59-pQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

[Michal Strba]

Btw, as is demonstrated in the proposal, sorting can be solved by passing a
comparator to the function:

```go
func Sort(a []gen T, less func(T, T) bool)
```

This is actually a far more flexible way than sorting based on an operator
or a `Less` method. Sorting based on an operator or `Less` limits each type
to one way of sorting. But, by passing a comparator, you can sort any type,
any way you like. You can sort number in ascending, descending order, sort
structs by one field, sort them by another. Without any need to introduce
new types, operators, or methods.

pi 31. 5. 2019 o 17:46 Robert Engels  napísal(a):

>
> Is that really true though? You can have one package that defines min/max
> for the built-in types (because it uses operators), and then one that uses
> method(s) Less() and Equals() that works with generics.
>
> A similar technique can be used in sorting.
>
>
>
> -Original Message-
> >From: David Riley 
> >Sent: May 31, 2019 9:05 AM
> >To: Robert Johnstone 
> >Cc: golang-nuts 
> >Subject: Re: [go-nuts] Go 2 generics counterproposal: giving up
> restricting types
> >
> >Because Min and Max are very good and simple indicators of whether the
> mechanism is generic enough to handle a fairly common idiom: small
> functions for similarly behaved items, say comparable items, which are
> annoying and repetitive to write for every data type which might support
> the operation (not to mention the fact that increases the surface area for
> errors).
> >
> >It's also worth noting that if Min and Max can't be written in a generic
> system, it's likely that Sort can't, either.
> >
> >If the purpose of a generic system is to reduce repetitive code in a
> readable way, it's probably not doing its job very well if it can't do Min
> and Max.  They're good canaries.
> >
> >
> >- Dave
> >
> >
> >> On May 31, 2019, at 9:06 AM, Robert Johnstone 
> wrote:
> >>
> >> Hello,
> >>
> >> I'm not sure that Min and Max need to be in the 80%.  It's annoying to
> write them repeatedly, but they are also very short.  The place where I
> typically miss generics is larger chunks of code, such as concurrency
> patterns.  I'm certain others are looking at datatypes.  Why do Min and Max
> need to be in the 80%?
> >>
> >> Robert
> >>
> >>
> >> On Thursday, 30 May 2019 14:26:34 UTC-4, Ian Lance Taylor wrote:
> >> One of my guidelines for an acceptable generics proposal is that
> >> people can write Min and Max.  Your proposal admits that it doesn't
> >> permit that.  I think that is a problem.  I'm fine with the general
> >> idea of "do 80% of the job" but in practice people really do want to
> >> write Min and Max.  I think they are part of the 80% that needs to be
> >> handled, not the 20% that can be omitted.
> >>
> >> --
> >> 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/e91e761e-92cd-452a-a387-e0741ebacd66%40googlegroups.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.
> >To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/A5807C0F-B951-45A1-9EBE-00629FE40B22%40gmail.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/176439122.1772.1559317546587%40wamui-hyena.atl.sa.earthlink.net
> .
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAO6k0ut5-TdUumxZXdW3a9Ut3k5S42nD%3DhTqYWsCv%3DcZTZi%2BpA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Interesting public commentary on Go...

[Devon H. O'Dell]

Maybe this story about suggesting the murder of a colleague is supposed to
be a tongue-in-cheek joke, but I want to push back heavily against it. And
I’m sorry that this is devolving significantly from the original topic, but
I don’t think this should slide by.

Though my professional experience is limited to “just” a bit under 20
years, this story embodies a culture I want to see change in both
professional and open source environments. This is a culture that makes
neophyte programmers — indeed even some with experience — live in a
constant state of fear. I think back to a job I had about a decade ago
where I was so bent on outperforming all my colleagues, I missed an
opportunity to help a junior developer improve. This person was doing
terribly by all measurable metrics (at least compared to the other
colleagues), but nobody intervened to help them improve. I remember that
person saying to several people — and this was said in their exit interview
— that a big reason they quit was that they lived in a constant state of
fear about being fired. That’s neither healthy nor ok for the work culture
to have supported.

Eventually, I decided to try to help this person after they left. This was
through  comments left on their blog. In retrospect these comments read
more as attacks or attempts to boost my own image over theirs. This person
blocked me on Twitter many years ago and disabled comments on their blog.

I regret this in its entirety. I can’t imagine looking back at a time I
suggested shooting someone, thinking it was funny, and sharing that
globally on an open source list with a CoC to be inviting and welcoming to
neophytes.

Having since successfully mentored individuals into systems programming
teams, I can’t imagine working in an environment that would tolerate such a
comment. If I heard such a thing today, I would make it clear that such
commentary is unacceptable, if not file a complaint with HR.

Having also worked with people who seem immune to learning, I understand
that helping folks can be a drain, especially when it’s not successful. But
suggesting shooting a person is just not ok, and to be frank, it doesn’t
make the story funny and you owe that person an apology. There are plenty
of other more constructive ways to handle such a situation.

Kind regards,

—dho


On Thu, May 30, 2019 at 16:33 David Skinner  wrote:

> I only rarely use generics in Go. When I do so, it is implemented using
> the +generate. The repos with my generics stuff is not public. If they
> were, they might be incomprehensible. While I rather like Fo, the thought
> of C++ style generics makes me cringe. Code must compile but it needs to be
> readable.
>
> I am very old school, I started programming with 8008 machine code. If
> something does not meet my needs, I may complain, but I may just write what
> I need. Go does not have generics but it is very easy for any user to
> implement generics in a variety of ways on an as needed basis. The thing
> is, I am not committed to Go, I am willing to use whatever works best for
> me, and right now that is Go, and I believe that that is the result of the
> experience of the Go team residing at Google in working as a team.
>
> I remember doing a code review at Sierra Online, it was a metrics project
> to evaluate employee performance, one programmer was so bad, I asked the
> head of the programming department to have him shot. He said, you want him
> fired? No, I want him shot, if you fire him, he will go and write bad code
> somewhere else. For some reason I do not understand, the company had a
> policy against shooting programmers that violated the style guidelines.
>
> When this is your life and your livelihood, it is easy to get emotional.
> Right now, I am still saying Thank you Google, and Thank you to the Go Dev
> Team. Well Done! Hope you do better next year. :)
>
>
>
> On Thursday, May 23, 2019 at 8:18:25 AM UTC-5, lgo...@gmail.com wrote:
>>
>> https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGooglesLanguage
>>
> --
> 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/3e72df2e-e27d-4dbe-9545-8527bdce1e35%40googlegroups.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.
To view this discussion on the web visit 

[go-nuts] Re: Go Module Mirror and Checksum Database in Beta!

[wilk]

On 31-05-2019, Amnon Baron Cohen wrote:
> --=_Part_967_922323128.1559316498912
> Content-Type: multipart/alternative; 
>   boundary="=_Part_968_1050003518.1559316498912"
>
> --=_Part_968_1050003518.1559316498912
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> See https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md
>
> The current behavior is not ideal from a security point of view.
> So it is good that 1.13 is fixing this.
> And unless the fix is default, most users will not get the benefit.

I see, thanks.

Is there a way to test proxy.golang.org with go1.12 if we have private
dependencies ?

-- 
William Dodé

-- 
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/qcrl7s%243g0s%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Announcing NSWrap -- a comprehensive Objective-C binding generator for MacOS

[Greg Pomerantz]

Also I don't think an API is going to assume or require ARC -- as far as I 
understand it, ARC is just a compiler shortcut that adds retain and release 
calls so the programmer doesn't have to, it is not any sort of runtime 
memory management or garbage collection system. As long as Clang has a 
-fno-objc-arc flag, there should be no problem turning ARC off.

On Friday, May 31, 2019 at 11:51:01 AM UTC-4, Robert Engels wrote:
>
> Isn't a lack of ARC support a critical limitation, as ARC is required 
> going forward, and many of the newer API's assume ARC behind the scenes?
>
> -Original Message- 
> From: Greg Pomerantz 
> Sent: May 30, 2019 8:25 AM 
> To: golang-nuts 
> Subject: [go-nuts] Announcing NSWrap -- a comprehensive Objective-C 
> binding generator for MacOS 
>
> I have been working on a binding generator that can read MacOS header 
> files and provide bindings for Objective-C interfaces and library 
> functions. NSWrap can also automatically generate classes implementing one 
> or more named protocols or subclassing a specified class.
>
> The automatically generated Go types implement method inheritance, and 
> overloaded method names are disambiguated. Variadic functions and methods 
> are supported and pointers to pointers are converted into slices. You can 
> create selectors (to assign actions to NSControl objects, for example) and 
> access Objective-C memory management methods (other than Automatic 
> Reference Counting), including AutoreleasePools.
>
> An example Cocoa application is provided in 24 lines of Go code. A 
> text-mode Bluetooth Low Energy heart rate monitor in pure Go is 127 lines. 
> The official git repository is linked below. This is the first release, so 
> expect plenty of rough edges.
>
> https://git.wow.st/gmp/nswrap
>
> -- 
> 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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/15be0140-b994-4692-9062-4792be74a8f9%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5ff1a68f-c379-4ea7-9177-1a4e15f899a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Announcing NSWrap -- a comprehensive Objective-C binding generator for MacOS

[Greg Pomerantz]

ARC support should be doable, it would mean at least i) using bridging 
casts instead of void* for every Objective-C object, and ii) disabling 
retain, release and autorelease methods, and disallow NSAutoreleasePool 
class.

On Friday, May 31, 2019 at 11:51:01 AM UTC-4, Robert Engels wrote:
>
> Isn't a lack of ARC support a critical limitation, as ARC is required 
> going forward, and many of the newer API's assume ARC behind the scenes?
>
> -Original Message- 
> From: Greg Pomerantz 
> Sent: May 30, 2019 8:25 AM 
> To: golang-nuts 
> Subject: [go-nuts] Announcing NSWrap -- a comprehensive Objective-C 
> binding generator for MacOS 
>
> I have been working on a binding generator that can read MacOS header 
> files and provide bindings for Objective-C interfaces and library 
> functions. NSWrap can also automatically generate classes implementing one 
> or more named protocols or subclassing a specified class.
>
> The automatically generated Go types implement method inheritance, and 
> overloaded method names are disambiguated. Variadic functions and methods 
> are supported and pointers to pointers are converted into slices. You can 
> create selectors (to assign actions to NSControl objects, for example) and 
> access Objective-C memory management methods (other than Automatic 
> Reference Counting), including AutoreleasePools.
>
> An example Cocoa application is provided in 24 lines of Go code. A 
> text-mode Bluetooth Low Energy heart rate monitor in pure Go is 127 lines. 
> The official git repository is linked below. This is the first release, so 
> expect plenty of rough edges.
>
> https://git.wow.st/gmp/nswrap
>
> -- 
> 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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/15be0140-b994-4692-9062-4792be74a8f9%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/dcfda64a-22ad-4977-84cf-015124c646ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Announcing NSWrap -- a comprehensive Objective-C binding generator for MacOS

[Robert Engels]

Isn't a lack of ARC support a critical limitation, as ARC is required going forward, and many of the newer API's assume ARC behind the scenes?-Original Message-
From: Greg Pomerantz 
Sent: May 30, 2019 8:25 AM
To: golang-nuts 
Subject: [go-nuts] Announcing NSWrap -- a comprehensive Objective-C binding generator for MacOS

I have been working on a binding generator that can read MacOS header files and provide bindings for Objective-C interfaces and library functions. NSWrap can also automatically generate classes implementing one or more named protocols or subclassing a specified class.The automatically generated Go types implement method inheritance, and overloaded method names are disambiguated. Variadic functions and methods are supported and pointers to pointers are converted into slices. You can create selectors (to assign actions to NSControl objects, for example) and access Objective-C memory management methods (other than Automatic Reference Counting), including AutoreleasePools.An example Cocoa application is provided in 24 lines of Go code. A text-mode Bluetooth Low Energy heart rate monitor in pure Go is 127 lines. The official git repository is linked below. This is the first release, so expect plenty of rough edges.https://git.wow.st/gmp/nswrap



-- 
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/15be0140-b994-4692-9062-4792be74a8f9%40googlegroups.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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/128011660.1813.1559317842414%40wamui-hyena.atl.sa.earthlink.net.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

[Robert Engels]

Is that really true though? You can have one package that defines min/max for 
the built-in types (because it uses operators), and then one that uses 
method(s) Less() and Equals() that works with generics.

A similar technique can be used in sorting.



-Original Message-
>From: David Riley 
>Sent: May 31, 2019 9:05 AM
>To: Robert Johnstone 
>Cc: golang-nuts 
>Subject: Re: [go-nuts] Go 2 generics counterproposal: giving up restricting 
>types
>
>Because Min and Max are very good and simple indicators of whether the 
>mechanism is generic enough to handle a fairly common idiom: small functions 
>for similarly behaved items, say comparable items, which are annoying and 
>repetitive to write for every data type which might support the operation (not 
>to mention the fact that increases the surface area for errors).
>
>It's also worth noting that if Min and Max can't be written in a generic 
>system, it's likely that Sort can't, either.
>
>If the purpose of a generic system is to reduce repetitive code in a readable 
>way, it's probably not doing its job very well if it can't do Min and Max.  
>They're good canaries.
>
>
>- Dave
>
>
>> On May 31, 2019, at 9:06 AM, Robert Johnstone  
>> wrote:
>> 
>> Hello,
>> 
>> I'm not sure that Min and Max need to be in the 80%.  It's annoying to write 
>> them repeatedly, but they are also very short.  The place where I typically 
>> miss generics is larger chunks of code, such as concurrency patterns.  I'm 
>> certain others are looking at datatypes.  Why do Min and Max need to be in 
>> the 80%?
>> 
>> Robert
>> 
>> 
>> On Thursday, 30 May 2019 14:26:34 UTC-4, Ian Lance Taylor wrote:
>> One of my guidelines for an acceptable generics proposal is that 
>> people can write Min and Max.  Your proposal admits that it doesn't 
>> permit that.  I think that is a problem.  I'm fine with the general 
>> idea of "do 80% of the job" but in practice people really do want to 
>> write Min and Max.  I think they are part of the 80% that needs to be 
>> handled, not the 20% that can be omitted. 
>> 
>> -- 
>> 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/e91e761e-92cd-452a-a387-e0741ebacd66%40googlegroups.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.
>To view this discussion on the web visit 
>https://groups.google.com/d/msgid/golang-nuts/A5807C0F-B951-45A1-9EBE-00629FE40B22%40gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/176439122.1772.1559317546587%40wamui-hyena.atl.sa.earthlink.net.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go Module Mirror and Checksum Database in Beta!

[Amnon Baron Cohen]

See https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md

The current behavior is not ideal from a security point of view.
So it is good that 1.13 is fixing this.
And unless the fix is default, most users will not get the benefit.

Anyone who wants to old behavior just needs to set two environment vars.

On Friday, 31 May 2019 14:15:28 UTC+1, wilk wrote:
>
> On 30-05-2019, Katie Hockman wrote: 
>
> > The module mirror at proxy.golang.org serves the go command=E2=80=99s 
> proxy 
> > protocol. The Go 1.13 development tree uses this mirror for all module 
> > downloads by default. See the go command documentation at tip 
> > 
> > for details. To make earlier versions of the go command use it (when in 
> > module mode), set GOPROXY=3Dhttps://proxy.golang.org. 
>
> Could you explain why this option will be default and not opt-in ? 
> It can break current workflow, for example with private repos. 
>
> Thanks 
>
> -- 
> William Dodé 
>
>

-- 
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/d3c61f54-fff3-46c9-8b8d-275686e2def1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

[David Riley]

Because Min and Max are very good and simple indicators of whether the 
mechanism is generic enough to handle a fairly common idiom: small functions 
for similarly behaved items, say comparable items, which are annoying and 
repetitive to write for every data type which might support the operation (not 
to mention the fact that increases the surface area for errors).

It's also worth noting that if Min and Max can't be written in a generic 
system, it's likely that Sort can't, either.

If the purpose of a generic system is to reduce repetitive code in a readable 
way, it's probably not doing its job very well if it can't do Min and Max.  
They're good canaries.


- Dave


> On May 31, 2019, at 9:06 AM, Robert Johnstone  wrote:
> 
> Hello,
> 
> I'm not sure that Min and Max need to be in the 80%.  It's annoying to write 
> them repeatedly, but they are also very short.  The place where I typically 
> miss generics is larger chunks of code, such as concurrency patterns.  I'm 
> certain others are looking at datatypes.  Why do Min and Max need to be in 
> the 80%?
> 
> Robert
> 
> 
> On Thursday, 30 May 2019 14:26:34 UTC-4, Ian Lance Taylor wrote:
> One of my guidelines for an acceptable generics proposal is that 
> people can write Min and Max.  Your proposal admits that it doesn't 
> permit that.  I think that is a problem.  I'm fine with the general 
> idea of "do 80% of the job" but in practice people really do want to 
> write Min and Max.  I think they are part of the 80% that needs to be 
> handled, not the 20% that can be omitted. 
> 
> -- 
> 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/e91e761e-92cd-452a-a387-e0741ebacd66%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/A5807C0F-B951-45A1-9EBE-00629FE40B22%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go Module Mirror and Checksum Database in Beta!

[wilk]

On 30-05-2019, Katie Hockman wrote:

> The module mirror at proxy.golang.org serves the go command=E2=80=99s proxy
> protocol. The Go 1.13 development tree uses this mirror for all module
> downloads by default. See the go command documentation at tip
>
> for details. To make earlier versions of the go command use it (when in
> module mode), set GOPROXY=3Dhttps://proxy.golang.org.

Could you explain why this option will be default and not opt-in ?
It can break current workflow, for example with private repos.

Thanks

-- 
William Dodé

-- 
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/qcr9cj%2464gr%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

[Robert Johnstone]

Hello,

I'm not sure that Min and Max need to be in the 80%.  It's annoying to 
write them repeatedly, but they are also very short.  The place where I 
typically miss generics is larger chunks of code, such as concurrency 
patterns.  I'm certain others are looking at datatypes.  Why do Min and Max 
need to be in the 80%?

Robert


On Thursday, 30 May 2019 14:26:34 UTC-4, Ian Lance Taylor wrote:
>
> One of my guidelines for an acceptable generics proposal is that 
> people can write Min and Max.  Your proposal admits that it doesn't 
> permit that.  I think that is a problem.  I'm fine with the general 
> idea of "do 80% of the job" but in practice people really do want to 
> write Min and Max.  I think they are part of the 80% that needs to be 
> handled, not the 20% that can be omitted. 
>

-- 
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/e91e761e-92cd-452a-a387-e0741ebacd66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

[Michal Strba]

@Ian, I have been thinking and I’ve come up with a possible solution to
yours and some other problems. I’d love to hear your thoughts on it. Note,
that this is a very fresh idea.

I’m addressing two problems here:

   1.

   Inability to do Min/Max and other generic numeric functions.
   2.

   There are a few kinds of generic parameters, but the kind is always
   implicit. This can be a problem because changing the body of a function can
   result in a backward-incompatible change, even when the signature remains
   the same.

Here are the ideas (also described in the proposal now, in the section
called ‘Further ideas’).

The kind of a generic parameters is currently completely implicit. Some
annotation could be added. One possible syntax could be like this:

   1. gen n for generic array lengths.
   2. gen T for arbitrary types (convertible to interface{}).
   3. gen eq T for equalable types (comparable with == and usable as map
   keys).
   4. gen num T for numeric types (with operators like +, -, <, …).

Array lengths and arbitrary types can have the same notation because it’s
always possible to distinguish them by context. Alternatively, they could
be distinguished by capitalization (lower-case for array lengths,
upper-case for types).

Syntax-wise, eq and num would not be keywords on their own. Rather, gen eq
and gen num would be two-word keywords.

The syntax is rather ad-hoc, I admit. It’s a very fresh idea, completely
open to refinement. However, since there are only four cases, an ad-hoc
syntax may actually be the right choice.

It’s also easily extensible with new possible “contracts”, but I’d
generally advise against that.

The addition of the num restriction would actually enable many cool things.
First, the Min/Max functions:

func Min(x, y gen num T) T {
if x < y {
return x
}
return y
}

It would also be useful for generic math types, like vector and matrices.
The matrix example above uses float64, but it could be generalized to all
numeric types.

As an example, let’s take a look at a possible implementation of a 2D
vector type:

type Vec2(T) struct {
X, Y T
}

There are no restrictions specified in the type definition. This is because
it’s methods and functions that require restrictions, not the types
themselves. For example, this String method requires no restrictions:

func (u Vec2(gen T)) String() string {
return fmt.Sprintf("(%v, %v)", u.X, u.Y)
}

This Eq method requires the types to be comparable with ==:

func (u Vec2(gen eq T)) Eq(v Vec2(T)) bool {
return u.X == v.X && u.Y == v.Y
}

But, this Add method requires the types to be numeric:

func (u Vec2(gen num T)) Add(v Vec2(T)) Vec2(T) {
return Vec2(T){u.X+v.X, u.Y+v.Y}
}

Consequently, Vec2([]float64) would only have the String method,
Vec2(string) would have the Eq method in addition, and Vec2(float64),
Vec2(int32), and so on, would have all the methods.

Yes, the idea basically is to introduce two "contracts" into the system.
However, there's no ability to create own contracts and the syntax is very
concise and non-disruptive. I believe this would really cover the vast
majority of use-cases.

pi 31. 5. 2019 o 14:05  napísal(a):

> On 5/31/19, Nick Keets  wrote:
> ...
> > This proposal is very interesting and seems to fit nicely into Go, with
> > minimal disruption. And speaking personally, it would cover 99% of my
> needs
> > for generics (I'm not that interested in Min/Max, but writing functions
> to
> > get map keys gets old fast).
> Interesting, could you please share the problems where the usual
> iterating idiom is not good enough?
>
> --
> 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/CA%2Bctqro9o-RAa6QRVCEQ%2BPu_tre%2BCtJQZaP4LbBTB_6LQntWyg%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAO6k0usrzSrh1j-xboqtxh8jJCz0eRDpfvTggfgi-0%3D10XhNoA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Go package manager

[yashish . dua]

Hi everyone!

I recently build an interesting Go tool - GPM (Go Project Manager). It 
allows you to build and manage go projects. Ont op, it also allows to 
update version of Go from cli.
Check it out: https://github.com/YashishDua/gpm

Feedback is appreciated!

-- 
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/d37b5ae7-187e-43b6-b7af-ecb8515039ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

[fgergo]

On 5/31/19, Nick Keets  wrote:
...
> This proposal is very interesting and seems to fit nicely into Go, with
> minimal disruption. And speaking personally, it would cover 99% of my needs
> for generics (I'm not that interested in Min/Max, but writing functions to
> get map keys gets old fast).
Interesting, could you please share the problems where the usual
iterating idiom is not good enough?

-- 
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/CA%2Bctqro9o-RAa6QRVCEQ%2BPu_tre%2BCtJQZaP4LbBTB_6LQntWyg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

[Nick Keets]

On Thu, May 30, 2019 at 9:26 PM Ian Lance Taylor  wrote:

> One of my guidelines for an acceptable generics proposal is that
> people can write Min and Max.  Your proposal admits that it doesn't
> permit that.  I think that is a problem.  I'm fine with the general
> idea of "do 80% of the job" but in practice people really do want to
> write Min and Max.  I think they are part of the 80% that needs to be
> handled, not the 20% that can be omitted.
>

 At some point we should decide if a 90% solution is possible at all and if
not, maybe a 80% solution is what we should aim.

This proposal is very interesting and seems to fit nicely into Go, with
minimal disruption. And speaking personally, it would cover 99% of my needs
for generics (I'm not that interested in Min/Max, but writing functions to
get map keys gets old fast).

-- 
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/CAPKajN6cC1oDZxmi0gJ6-GEMaVHEF7NKF7EyOcuOeyMpS7Dt-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.