[go-nuts] Re: are Go generics more like C++ or more like Java?

[Markus Heukelom]

Correction:

- it must be possible to express that T is comparable (so that you can use 
map[K]V, were K must be comparable)
- it must be possible restrict T to a concrete list of types (f.e. min(a, b 
T) T must be possible to write)

On Friday, February 25, 2022 at 11:13:01 AM UTC+1 Markus Heukelom wrote:

> I think the consensus in the Go community is to refrain from comparing Go 
> language features with other programming languages. Rationale ~:
>
> - it is highly contentious
> - it is very difficult to answer, it's like asking "is purple more blue or 
> more red"
> - no matter the answer, it will not help you a lot to write better 
> programs or be more productive in Go
>
> However, maybe your real question is more like "what are/were the guiding 
> principals for generics in Go?".   As far as I understand, generics in Go 
> follow the same principles as other language features in Go:
>
> - compilation should be very fast, but trade-offs are allowed so it does 
> not need to be maximally fast
> - language features should be as orthogonal as possible, but trade-offs 
> are allowed so they don't need to be maximally orthogonal
> - it should be a simple as possible but no simpler
> - ... 
>
> For generics this has resulted in:
>
> - exotic use-cases are not supported (for example having an integer 
> *constant* as *generic parameter*, such as you see in C++ fixed size matrix 
> templates, is not supported)
> - it must be possible to express that T is comparable (f.e. min(a, b T) T 
> must be possible to write)
> - it must be possible restrict T to a concrete list of types 
> - it must be possible to restrict T to a type with method set that equals 
> that of some interface (I *personally* think this violates the principle of 
> orthogonality too much and will lead to confusion and design debate)  
>
> Of course, neither list is exhaustive and is only my personal 
> understanding of things.
>
> -Markus
>
> On Wednesday, February 23, 2022 at 9:41:14 PM UTC+1 Jason E. Aten wrote:
>
>> Back in 2009, Russ wrote a blog on generics, talking about the tradeoffs 
>> in providing generics:
>>
>> "The generic dilemma is this: *do you want slow programmers, slow 
>> compilers and bloated binaries, or slow execution times? " -- *
>> https://research.swtch.com/generic
>>
>> I haven't had the bandwidth to follow the generics detailed discussions.  
>> I was just curious, at a high level, for creating a mental model of Go's 
>> generics: which approach was taken?
>>
>> Thanks!
>>
>> J
>>
>

-- 
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/3740af77-31f0-4423-b264-aaeb0cfbe49dn%40googlegroups.com.

[go-nuts] Re: are Go generics more like C++ or more like Java?

[Markus Heukelom]

I think the consensus in the Go community is to refrain from comparing Go 
language features with other programming languages. Rationale ~:

- it is highly contentious
- it is very difficult to answer, it's like asking "is purple more blue or 
more red"
- no matter the answer, it will not help you a lot to write better programs 
or be more productive in Go

However, maybe your real question is more like "what are/were the guiding 
principals for generics in Go?".   As far as I understand, generics in Go 
follow the same principles as other language features in Go:

- compilation should be very fast, but trade-offs are allowed so it does 
not need to be maximally fast
- language features should be as orthogonal as possible, but trade-offs are 
allowed so they don't need to be maximally orthogonal
- it should be a simple as possible but no simpler
- ... 

For generics this has resulted in:

- exotic use-cases are not supported (for example having an integer 
*constant* as *generic parameter*, such as you see in C++ fixed size matrix 
templates, is not supported)
- it must be possible to express that T is comparable (f.e. min(a, b T) T 
must be possible to write)
- it must be possible restrict T to a concrete list of types 
- it must be possible to restrict T to a type with method set that equals 
that of some interface (I *personally* think this violates the principle of 
orthogonality too much and will lead to confusion and design debate)  

Of course, neither list is exhaustive and is only my personal understanding 
of things.

-Markus

On Wednesday, February 23, 2022 at 9:41:14 PM UTC+1 Jason E. Aten wrote:

> Back in 2009, Russ wrote a blog on generics, talking about the tradeoffs 
> in providing generics:
>
> "The generic dilemma is this: *do you want slow programmers, slow 
> compilers and bloated binaries, or slow execution times? " -- *
> https://research.swtch.com/generic
>
> I haven't had the bandwidth to follow the generics detailed discussions.  
> I was just curious, at a high level, for creating a mental model of Go's 
> generics: which approach was taken?
>
> Thanks!
>
> J
>

-- 
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/1a82fc73-0916-4619-a22b-ba624ad24eden%40googlegroups.com.

Re: [go-nuts] pkg.go.dev: navigation index is confusing

[Markus Heukelom]

>
> @Markus: I normally use browser's search function to get to the function
> and it works well with pkg.go.dev too.
>
>
Using the search function only works if you know the name of the function.

Very common examples when this doesn't work:

Package HTTP:

If you vaguely remember a function name, for example "TrimPrefix" (note:
it's actually "StripPrefix"), search obviously doesn't work. But it's
impossible to just scan through the list of functions in the index to find
"StripPrefix". You have to guess "it probably returns a Handler" or "It
probably is a type that implements Handler" and then looking under the
type.  But the much simpler use case, just going through a list of
functions, is not supported.  Which is difficult and frustrating.

Package x/net/html

The function "Parse" is (arguably) the most important function. But it is
not in the function index (but Render() is, adding to the confusion).
Worse, even if you guessed that there should be a function with "Parse"
in it,  the word "Parse" is very common in the documentation, so browser
search also doesn't work well.



I think it will be very useful to have all functions under "Functions" so
that you can just scan through it when you need it.



-Markus




> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/8nyrNxX0Oq8/unsubscribe.
> To unsubscribe from this group and all its topics, 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/20210903131341.2742b5b0%40xmint
> .
>

-- 
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/CAMoB8rU1H6kxArV7xdona0GwZjafvdKUA7LvWfDw1YhADgDH7w%40mail.gmail.com.

[go-nuts] pkg.go.dev: navigation index is confusing

[Markus Heukelom]

The main issue is that most package functions are not actually listed under 
"Functions". 

For example, I wanted to lookup StripPrefix in the http package. I could 
not find it in the package documentation function index. It was not there. 

So I looked under Types (maybe I did remember it incorrectly?). It wasn't 
listed there either. 

But I was quite sure it existed. 

I eventually found it using the Jump-To bar.

So, turns out, the function is actually listed under the type "Handler", 
probably because it implements that interface. 

Well. Cool.  

That's helpful indeed if you are interested to see which types implement 
"Handler" (even though the index does not state that "Handler" is an 
interface so you first wonder 1 minute why "Handler" has types hanging 
under it instead of methods, but ok).

However, the *primary* use of the index is to *quickly* find that function 
you're looking for.  That's what indexes are for.Turns out, it just 
only lists like half of the functions - if you're lucky.

Another example is the x/net/html package. 

The "Parse" function is arguably the most important function of the whole 
package. Well - you can only find Parse *under* the Node type, which is by 
default collapsed.

Another fun example is the documentation for type http.FileSystem. It 
contains this text:

"See the FileServer function to convert a FileSystem to a Handler." 

Awesome! Let's look up that FileServer function in the index.

Well. It's not there.

No. 

You are expected to be so smart to realise that FileServer of course 
implements the Handler interface and is therefore only listed under the 
collapsed Handler type. Maddening.

Proposal: just list all functions in the index please.

NOTE: I admire Go & Go.dev. My exaggerative style is just used to 
illustrate my point.

NOTE: My apologies if this is not the place for go.dev feedback. Please 
redirect me.

NOTE: I know that the index in the old package docs also has this 
structure. It has somewhat the same issue, but at least you could scroll 
through it a scan for function  names.







 

-- 
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/15cb6bbd-83fc-44f7-a5fc-a922b7112461n%40googlegroups.com.

[go-nuts] Type assertion: panic: value method time.Time.String called using nil *Time pointer"

[Markus Heukelom]

Code:

package main

import (
"fmt"
"time"
)

func main() {

var my *time.Time
var any interface{}
any = my

stringer, ok := any.(fmt.Stringer)
println(ok) // "true", but I expected "false", as the receiver for
time.Time.String() is (t time.Time), not (t *time.Time)
println(stringer.String()) // "panic: value method time.Time.String called
using nil *Time pointer"
}

playground: https://play.golang.org/p/qVyr_u11Tku

Question 1:

I don't understand when the type assertion succeeds here, as the receiver
for time.Time.String() is (t time.Time), not (t *time.Time). The language
specification states:

"If T is an interface type, x.(T) asserts that the dynamic type of x
implements the interface T."

(from: https://golang.org/ref/spec#Type_assertions)

Does this mean that I should read "dynamic type of x" as "the actual type
of x" or the "dereferenced type of x if x is a pointer"? Is there a formal
definition of "dynamic type of x"? Or should I look at a different part of
the spec?

Question 2:

Accepting that I get "true" on a pointer to a type that implements
fmt.Stringer, how can I check that I can actually safely call
stringer.String()? I.e. how can I prevent the runtime panic? Without using
reflection. Please note: I do not mean checking if there is a nil pointer
in x: the error is not raised by the time.String() implementation, in fact
it might work fine with nil pointers were it defined using a pointer
receiver. It seems the error is thrown by the runtime.

Thanks,

Markus

-- 
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/CAMoB8rV%3DQTcHXRC4KvJfcHC9zo8oAE0LR9%3D4ywVb_s-iejX14A%40mail.gmail.com.

[go-nuts] Re: Type parameters syntax... Can it be improved?

[Markus Heukelom]

I agree here that there is a lot of repetition in the function definitions 
of let's say a generic math package:

types Numbers { type float32,float64,  }

func Abs[T Floats](a T) T {}
func Sin[T Floats](a T) T {}  
func Cos[T Floats](a T) T {}  

etc. (50 orso more?)

It feels a bit redundant and "noisy" to the eye. I think in practice, any 
good generic packages will only use maybe one or two type parameters 
constrainsts (interfaces), and likewise most types (functions) will use 
very similar if not the same type parameters lists.

So I tried to come up with a solution similar to yours by predefining T 
which could then be directly. But as Ian illustrated there's issues that 
are not naturally solved. So I agree that the current proposal is simpler 
(with the downside of being a bit "noisier" wrt such a proposal).

Another solution that comes to mind would be to allow to some sort of 
grouping structure:

generic [T Numbers] {
func Abs(a T) T {}
func Sin(a T) T {}  
func Cos(a T) T {}  
}

This would give all types within the group the same type parameters list.  
The grouping my also be useful for documentation. Obvious downside is the 
extra level of indentation on package level (although it nicely separates 
the generic types from concrete types, so maybe just getting used to). 
Another downside is the introduction of the "generic" keyword. 

-Markus


On Tuesday, March 23, 2021 at 10:16:44 PM UTC+1 atd...@gmail.com wrote:

> Quick question...
>
> Why do we need brackets to define a parametered function, struct etc...?
>
> Why not change Go kinds to accept either a type (would produce a regular, 
> function, structs, etc) or a new type parameter object that would implement 
> the constraints (would produce a generic function definition)
>
> for instance,
>
> type parameter T
>
> // [...]  some way to add constraint to T
>
> func Max(v T) T{...} 
>
> What are the brackets for? Just an idea.
>
>

-- 
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/b802e7fe-4f72-4804-8c23-ea55ac4a5de0n%40googlegroups.com.

[go-nuts] Re: Is there a final document on generics?

[Markus Heukelom]

On Tuesday, March 16, 2021 at 11:27:12 AM UTC+1 Haddock wrote:

>
>
> Therefore I wonder whether it would make sense for the Go core development 
> team to define a couple of generic interfaces for sets, lists, queues, 
> maps, etc. that are part of the standard library to prevent some 
> uncontrolled growth of all kind of generic collection libraries from 
> setting in. So I wanted to ask whether there are any plans that go in that 
> direction.
>
>
What about the Heap and List containers in the current stdlib? And in 
addition since the math.Max (and friends) function were often given as top 
examples of why generics are desired, I wonder if their generalised version 
are part of in the planned generics implementation path?  

Since both are not stated in the current design specification (or github 
proposal), I am assuming the answer is "no" to both questions. It would be 
wonderful though. Maybe initially as golang.org/x repos to not lock-in the 
design from the start? 

-Markus

 

> Thanks, Archilbald H.
>

-- 
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/86e9ee06-5549-439d-a07a-5f0769a69301n%40googlegroups.com.

[go-nuts] Re: What's the status/roadmap of geo/s2 library?

[Markus Heukelom]

I think your question is answered by s2/geo github  page itself 
(https://github.com/golang/geo):

"

*In Progress* Files that have some work done, but are probably not complete 
enough for general use in production code.

   - CellIndex - A queryable index of CellIDs.

etc



On Tuesday, January 26, 2021 at 7:23:09 PM UTC+1 Piotr Wieczorek wrote:

> Hi,
> I love golang seo s2 library, but one thing that's a bit annoying to me is 
> the fact that documentation (type/method comments) often refer to 
> functionality that's not implemented.
> For example, there is the CellIndex type, documentation of which suggests 
> using method IntersectingLabels or ClosestCellQuery none of which seem to 
> be implemented.
> In fact, I don't know if the CellIndex can be queried at all, as there are 
> no Query types that reference it.
> I was trying to find any open issues or a roadmap that could tell me if 
> someone is working on finishing this functionality, but I could find none.
> I could try to take stab at implementing it (although I don't think, I'm 
> smart enough or have enough domain knowledge), but maybe someone's already 
> working on it.
>
> I'd love if someone could share this information. :)
>
> Best,
> Piotr
>

-- 
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/1acfee6f-dc6e-43f5-93e9-bb962e57c989n%40googlegroups.com.

Re: [go-nuts] Re: Generics - please provide real life problems

[Markus Heukelom]

On Fri, Jan 1, 2021 at 2:16 PM Axel Wagner 
wrote:

> Hi,
>
> On Fri, Jan 1, 2021 at 1:41 PM Markus Heukelom 
> wrote:
>
>> One thing that comes to mind that is not supported by the current
>> proposal is the ability to express that T must be (any) struct.
>>
> […]
>>
> Another example is where you write a library that creates an RPC service
>> from any function that you provide:
>>
>
> Personally, given that in both of these cases you still need to use
> `reflect` and there's still a lot of type-errors that can happen, I feel
> the wins here are relatively minor. There definitely are some and if they
> could be added more or less "for free", I'd definitely support that. But I
> don't see, personally, how that could be done.
>


> As an example, a similar case is expressing that an argument must be a
> pointer - for example, for json.Unmarshal. It has a similar level of
> benefit (json.Unmarshal also still needs to use reflect to actually set
> fields or values) - but in that case, there is already a "free" way to
> achieve it with the design (that is, use `func Unmarshal[type T any](b
> []byte, p *T) error`).
>
>
>> On the other hand, I don't see a lot of cases myself where I would want
>> to call some method on T in a generic function, mainly because there's
>> already interfaces and helper function for this in Go if you need it.  For
>> example, you could say that a generic priority queue must call a method
>> Priority() on T, but that could be done in an equally type-safe way by
>> asking for a helper function to be provided with T (ie. func (T) int) with
>> the container.  There's the graph example in the generics proposal but I
>> think that that can have a likewise type-safe solution that doesn't need
>> the ability to call a method on T.
>>
>
> You could argue, that you don't actually *need* methods or interfaces at
> all. Instead of passing an `io.Reader`, you could pass a `func(p []byte)
> (int, error)`. And instead of passing an `io.ReadCloser` you could pass
> that func and a `func() error`. At the end of the day, an interface is just
> a table of functions.
>

That's true (although an interface is more than a table of functions: it
also a value and type pointer tuple at runtime - ie. you can use it as a
variant  etc.). My argument is that for generics it is -possibly- not that
inconvenient to go without methods (i.e. most of the benefit lies
elsewhere). Yes, it can be convenient or elegant in some cases but it comes
with quite high cost (in my view) wrt complicating the interface concept
with little benefit to type-safety (as opposed to generics in itself).  It
is more complicated because  now you also need to understand sum-types and
that methods are not allowed if you have a type list etc etc. This in
addition to understanding the mechanics when interfaces can be nil (think
of the pointer pit fall etc) and how to use type assertions in switch etc.

Another benefit of not allowing method calls on T is that you don't have to
choose whether to use io.Reader as a type parameter or as a runtime
interface when you design a function. That lack of not having to make that
choice is in my view  beneficial because it simplifies the programming
effort (less choices to make) and avoids discussions and opinion camps. The
drawback is that you lose some expressiveness / conciseness in writing some
generic containers (or algorithms).


>
> On the other hand I agree that an "interface" in its meaning of a
>> "declaration of a method set" applies equally well to compile time and
>> runtime. So the current argument is (I think) that generics is just the
>> application of interfaces at compile time instead of runtime.
>>
>
> I think the argument is rather "we want a way to constrain types and
> interfaces already provide a familiar way to express such constraints".
> It's just about re-using a familiar mechanic, instead of introducing a new
> one (in fact, the previous incarnation of contracts *would* have introduced
> a new mechanic and that was one of the main criticisms of it).
>


>
The issue I have with this is that it complicates (at least) the language
>> around the concept of "interface" at lot (just think about all the
>> documentation around interface that needs to be rewritten, and if someone
>> asks a question on a interface you first need to address if it's used
>> runtime or compile time, etc).
>>
>
> I do think interfaces change, but only to accommodate type-lists. I'm not
> a huge fan of that aspect of the design myself.
>

If no methods calls on T are allowed, then interfaces and generics can be
decoupled and just type lists could suffice (with "comparable

Re: [go-nuts] Re: Generics - please provide real life problems

[Markus Heukelom]

>> On Thursday, December 31, 2020 at 11:27:06 AM UTC+1 
axel.wa...@googlemail.com wrote:
>> I don't think the current draft lets us express very powerful 
invariants. And while I wouldn't really advocate to make that a target, I 
think it would be interesting to see more discussion of this area - i.e. 
more case-studies of where Go has type-safety problems and if the current 
design can address them.

One thing that comes to mind that is not supported by the current proposal 
is the ability to express that T must be (any) struct. For example, I have 
a ORM function that scans a sql row into a struct (using reflection in its 
implementation):

// dest must be a pointer to a struct or an error is returned 
func ScanIntoStruct(row *sql.Row, dest interface{})  error {}

If you could somehow express that dest must be a pointer to a struct I 
could move one type of runtime-error into a compile-time error type (i.e. 
the purpose of generics):

// sketch code
func ScanIntoStruct[S struct](row *sql.Row, dest *S)  // NOTE: 
implementation still calls an internal function that is not generic and 
uses reflection 

Another example is where you write a library that creates an RPC service 
from any function that you provide:

func ExposeAsRPC[T func](name string, f T) {}

Again, this would then prevent ExposeASPRC to be called with anything but a 
function. Note however that the signature of f could be anything. This 
would be helpful to if you want to expose a Go function in a scripting 
language etc. 

I am not saying this a big "type-safey" problem, just an example of 
something I have encountered. 

On the other hand, I don't see a lot of cases myself where I would want to 
call some method on T in a generic function, mainly because there's already 
interfaces and helper function for this in Go if you need it.  For example, 
you could say that a generic priority queue must call a method Priority() 
on T, but that could be done in an equally type-safe way by asking for a 
helper function to be provided with T (ie. func (T) int) with the 
container.  There's the graph example in the generics proposal but I think 
that that can have a likewise type-safe solution that doesn't need the 
ability to call a method on T.  

On the other hand I agree that an "interface" in its meaning of a 
"declaration of a method set" applies equally well to compile time and 
runtime. So the current argument is (I think) that generics is just the 
application of interfaces at compile time instead of runtime. The issue I 
have with this is that it complicates (at least) the language around the 
concept of "interface" at lot (just think about all the documentation 
around interface that needs to be rewritten, and if someone asks a question 
on a interface you first need to address if it's used runtime or compile 
time, etc). A second issue is that, in my opinion, it does not agree very 
well with the idea of "one way of doing things" / orthogonality in Go (as 
explained above). 

>> The third use-case I see for generics is to catch bugs by being able to 
express more complicated type-invariants in code. An example of that would 
be type-safety for context.Value 
 (or, 
similarly but subtly different, optional i

The context.Value example is maybe an example of something that to me feels 
(at least initially) as a suspicious application of generics. If 
context.Context is made generic (if this is what is meant) then all 
functions that use it, such as in the sql package, are forced to be generic 
too:

func (c *Conn) QueryContext[T any](ctx context.Context[T], query 
string, args ...interface{}) (*Rows, error) 


Before you know it everything is generic On the other hand,  maybe this 
is something that you just need to get used to and be very happy with 
after. My initial reaction would be that the right choice here would be to 
make context not generic as Value is only a "extra" customer user value 
that is not part of its main functionality/purpose. However, it would 
possibly be tempting to factor interface{} into a T if you don't think too 
much about it.


-Markus


-- 
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/28dfab48-9413-4658-9272-bcc79f73153fn%40googlegroups.com.

Re: [go-nuts] Re: Generics, please go away!

[Markus Heukelom]

On Tue, Dec 22, 2020 at 9:48 PM Ian Lance Taylor  wrote:

> On Tue, Dec 22, 2020 at 1:24 AM Markus Heukelom
>  wrote:
> >
> > Why not issue a poll on generics, was this ever done? (I could've missed
> it, I  am only following Go ~2 years). While the community has a vote in
> accepting/rejecting the current generics proposal, the community was never
> (really) asked if generics is desired in the first place and especially
> what the scope of generics should be. Is that correct?
>
> I don't know of a poll specifically about generics.  But for the past
> several years we've done a Go community survey, and every year there
> is significant support for adding generics to the language.  For
> example, although the results of the 2020 survey haven't been
> assembled yet, you can see the results of the 2019 survey at
> https://blog.golang.org/survey2019-results.  In that survey when asked
>



> "Which critical language features do you need that are not available
> in Go?", 25% of the survey takers answered the question, and of those
> 79% mentioned generics.  Previous years also showed support for adding
> generics.


Thanks for this, that's actually a lot higher than I would expect.

It could be of interest to see the percentage of people who answered
"generics" split by "years of any coding experience" and "years of go
experience" (graph 2 and 3 in the blog post).  It may be helpful in this
discussion for people to see if  their "peers" requested generics.

I am not against generics, it can definitely be useful in some cases,
although I too certainly worry quite a bit about the mess it can cause in
other languages. Generics is a great tool for over-engineering.


Of course this isn't definitive, since there was no clear
> way for people they say that do not want generics.  But it's also not
> definitive in a different direction, which is that by and large people
> who don't currently use Go didn't take the survey, and probably some
> of them would also want generics.
>
> So while Go is not and never has been a poll-driven language, I think
> it's reasonable to say that there is real support for adding generics.
>
>
> > Another thought:  there are many popular, type-safe programming language
> with generics already. So if you really need generics, there's plenty to
> pick from. There's not that many  without, I can only name Go and C. So if
> generics is added to Go there's far less choice to pick a modern type-safe
> language that doesn't have generics. It's a feature that makes Go quite
> special.
>
> Actually, C does have generics, through the preprocessor macro
>

mechanism.  It's difficult to write, but it does provide the same kind
> of functionality that would be available in Go if we added generics.

For example, here is a compile-time-type-safe vector implementation in
> C:
>
>
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/vec.h;h=cb871124ce2241402af05e4697a5e28904c462fb;hb=HEAD
>
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/vec.c;h=85274c4e00c202e680761cef516bd17bb58b6261;hb=HEAD
>
> Ian
>

-- 
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/CAMoB8rWJ%3DaOYYruQoJBrKY5NPGQHPdQZ8wSV%2BHSKMPSLofUrnw%40mail.gmail.com.

[go-nuts] Re: Generics, please go away!

[Markus Heukelom]

Why not issue a poll on generics, was this ever done? (I could've missed 
it, I  am only following Go ~2 years). While the community has a vote in 
accepting/rejecting the current generics proposal, the community was never 
(really) asked if generics is desired in the first place and especially 
what the scope of generics should be. Is that correct? 

Another thought:  there are many popular, type-safe programming language 
with generics already. So if you really need generics, there's plenty to 
pick from. There's not that many  without, I can only name Go and C. So if 
generics is added to Go there's far less choice to pick a modern type-safe 
language that doesn't have generics. It's a feature that makes Go quite 
special.

To me, the most worrisome thing about the current generics proposal is that 
there'll be a constant choice/preference fight between writing

func MyFunc(r io.Reader) error {}

- or - 

func MyFunc[T io.Reader](r T) error {}

I hope I am wrong, but I have the feeling the latter looks cooler to a lot 
of programmers out there. 


On Sunday, December 20, 2020 at 8:38:54 PM UTC+1 Martin Hanson wrote:

> I think people who want generics added to Go should go and program in Java 
> or C++.
>
> Adding generics to Go will ruin the beautiful simplicity of the language 
> and I haven't found a single example in which adding generics to Go pays 
> off.
>
> Even with the examples of having two almost identical functions reverse 
> some list, one of ints and one of strings, seriously!? We already have tons 
> and tons of open source reusable code that covers all use cases which 
> people complain about.
>
> Go was designed without generics purposefully from the start and Go is 
> fine just the way it is.
>
> Adding generics means that we're opening the door to the beginning of 
> bloating Go with all the crap that Java, C++ and all the other complex 
> languages has gotten over the years, and Go was designed specifically 
> without that clutter. So we add generics, then what? Classes?
>
> Adding generics to Go ruins that beautiful simplicity that went into the 
> design and the added complexity just isn't worth it! The standard library 
> have managed just fine without generics and so have we!
>

-- 
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/1fe5535e-9c1e-4fba-97da-1f840a284c82n%40googlegroups.com.

[go-nuts] Generics and methods on predeclared types

[Markus Heukelom]

Currently the predeclared types (int, bool, float32, string, etc) do not 
have any methods on them. It appears to me that if they would, the generic 
implementation for math.Min/Max etc could do without 'types' in interfaces 
(as is currently proposed).

For example:

type Sortable[T any] interface {
Compare(T other) int
}

Suppose that int, float64, string etc all predeclare the Compare(T) int 
method. Then

func Max[T Sortable[T]](a, b T) T {
if a.Compare(b) >= 0 {
return a
}
return b
}

Is this something that was considered or is this just a bad idea? (It would 
require that all predeclared types expose most operators in some method 
form). 

One obvious benefit is that Max works for any user type as well (instead of 
only predeclared types). Another benefit is that the interface{} concept 
would not need to be extended (at least for the purpose of generics) with 
type lists.

Markus


-- 
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/7afd3902-1529-4137-8377-88469de0c398n%40googlegroups.com.

[go-nuts] Re: Reduced error handling noice

[Markus Heukelom]

In this case, because you call the same function, you could also try a 
helper function:

// GetParameters retrieves multiple parameters using GetParameter.
func GetParameters(params ...string) ([]string, error) {
var values []string
for _, param := range params {
value, err := GetParameter(param)
if err != nil {
return nil, err // alternatively you could also collect & combine all errors
}
values = append(values, value)
}
return values, err
}


params, err := GetParameters("TENANT_ID", "CLIENT_ID", "CLIENT_SECRET")
if err != nil {
return err
}
tenantID, clientID, clientSecret := params[0], params[1], params[2]

On Wednesday, October 7, 2020 at 8:36:07 PM UTC+2 johan.ma...@dexyos.fr 
wrote:

> Hi, I'm looking for thoughts from some experienced go programmers on a 
> technique to reduce error handling verbosity. 
>
> The basic idea is to be optimistic over a few instructions, and then 
> combine many errors in to one. This gist and explains the idea (note the 
> absence of if err != nil {} )
>
> tenantID, err1 := store.GetParameter("TENANT_ID")
> clientID, err2 := store.GetParameter("CLIENT_ID")
> clientSecret, err3 := store.GetParameter("CLIENT_SECRET")
>
> globalErr := multierr.Combine(err1, err2, err3)
> return connection{
> tenantID,
> clientID,
> clientSecret,
> }, globalErr
>
> There's some more detail in a post 
> http://martinsson-johan.blogspot.com/2020/10/less-error-handling-noice-in-go.html.
>  
> I'm sure someone else has already proposed this, but I wasn't able to find 
> it. Grateful for pointers
>  
> While it seems sound to me I'm a very interested in what people from the 
> community thinks.
>
> Cheers
> Johan Martinsson
>
>

-- 
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/18f311c2-8575-4214-b0ae-6a107e16f453n%40googlegroups.com.

Re: [go-nuts] Question on the generics proposal and arrays

[Markus Heukelom]

On Wed, Oct 7, 2020 at 9:12 PM Howard C. Shaw III 
wrote:

> You said:
>
>> I was trying around with arrays and generics because slices are more
>> complex to reason about than arrays. For example, I introduced bugs into my
>> code by not being fully aware of slices overwriting original data when you
>> append to them and the capacity is not set correctly. So, when writing
>> critical code it could be safer to avoid slices if possible for
>> this reason. Another example:
>>
>
> In my experience, you either have a fixed array size in mind to begin with
> (as in a fixed array size in a struct for padding or matching a fixed size
> C array) or you should be using a slice anyway.
>
> The trouble mostly comes when you keep the array around after making a
> slice of it. If you are  going to be doing *any* manipulation of a slice,
> abandoning the underlying array and only carrying around slices gets rid of
> most such errors. A slice already IS effectively an 'array, generic on
> size.'
>

Hm, abandoning the underlying array does not really help I think:

u := []byte{0, 1, 2, 3}
a := u[0:2]
b := u[2:]
u = nil  // abandon u
a = append(a, 4)
fmt.Println(b) // [4, 3]!! not intended

Should be:

u := []byte{0, 1, 2, 3}
a := u[0:2:2] // use correct capacity!
b := u[2:len(u)] // use correct capacity!
u = nil // abandon u
a = append(a, 4)
fmt.Println(b) // [2, 3], ok!

Btw, I am not saying fixed arrays are a solution for this of course and I
agree it is not a big problem in practice as otherwise slices are really
handy.




-- 
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/MF1UzRrx9mU/unsubscribe.
> To unsubscribe from this group and all its topics, 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/08fe15f5-dff1-4651-b824-86266b3ce50bn%40googlegroups.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/CAMoB8rU4imEf5OdRi_0DXpH6y21r5kcw6UzXUPCz%3DQqpuwC3Hw%40mail.gmail.com.

Fwd: [go-nuts] Question on the generics proposal and arrays

[Markus Heukelom]

On Tue, Oct 6, 2020 at 7:45 PM Ian Lance Taylor  wrote:

> On Tue, Oct 6, 2020 at 6:32 AM Markus Heukelom 
> wrote:
> >
> > It appears to me the current proposal does not allow you to write a
> function that sorts an array of any size:
> >
> > func SortArray[T comparable](array [??]T, less func(a, b T) bool) [??]T
> {}
> >
> > Is it correct that this is not possible? Or is this expressed
> differently?
> >
> > To clarify, I am seeking for something like:
> >
> > func SortArray[T comparable, int n](array [n]T, less func(a, b T) bool)
> [n]T {}
>
> You are correct that the current design draft does not provide any
> mechanism for writing code that is generic across the dimension of an
> array.  This is mentioned in the list at
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#omissions
> .
>

Thanks, I missed this sentence.

I don't think it would be hard to add later if it seems useful.
>
>
Thanks, this is good to know. Because arrays are simpler types than slices
(slices are built using arrays), it would indeed make sense to add this
support (or at least at some point). Otherwise wrt generics, arrays would
be sort of second class, so to speak :)

That said, I don't think your suggested SortArray function would be a good
> API.  In Go arrays are passed by value, so this would copy the

entire array into the function, sort it, and then copy the entire
> array out.  It is trivial to turn an array into a slice, by writing
> a[:], so it would be more natural in Go to write Sort(a[:], less),
> which would let the caller decide whether to make a copy or not

I agree. But if you need both the original and the sorted array, it could
make sense. It was just meant as an example though.

I was trying around with arrays and generics because slices are more
complex to reason about than arrays. For example, I introduced bugs into my
code by not being fully aware of slices overwriting original data when you
append to them and the capacity is not set correctly. So, when writing
critical code it could be safer to avoid slices if possible for
this reason. Another example:

type block[T interface{}] struct {
next *block[T]
used int
items [BLOCKSIZE]T
}

Of course, items can be a slice here. But an array is simpler, and maybe
block is part of a container that is an alternative to slices. However,
BLOCKSIZE would be logical to make configurable and then you need to be
able to write methods that deal with  [BLOCKSIZE]T, or at least  [.]T,
where [.]T means "an array of T of any size".



> Here's two other examples that come to mind:
> >
> > type Number {types ...}
> > func DotProduct[T Number, int n](a, b [n]T) T {} // n can be any integer
> > func MultMatVec[T Number, rows, cols int](m [rows][cols]T, v [cols]T)
> [rows]T {}
>
> Agreed.
>
> Ian
>

-- 
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/CAMoB8rVWt%2BmpfHU%3D1RwdJngGji%2BwM-u9JVci0LcmyEgZnKBgOg%40mail.gmail.com.

[go-nuts] Question on the generics proposal and arrays

[Markus Heukelom]

It appears to me the current proposal does not allow you to write a 
function that sorts an array of any size:

func SortArray[T comparable](array [??]T, less func(a, b T) bool) [??]T {}

Is it correct that this is not possible? Or is this expressed differently?

To clarify, I am seeking for something like:

func SortArray[T comparable, int n](array [n]T, less func(a, b T) bool) 
[n]T {} 

Here's two other examples that come to mind:

type Number {types ...}
func DotProduct[T Number, int n](a, b [n]T) T {} // n can be any integer
func MultMatVec[T Number, rows, cols int](m [rows][cols]T, v [cols]T) 
[rows]T {} 


Thanks, Markus

-- 
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/7be56389-06ea-4cf4-89a0-127b05540544n%40googlegroups.com.

Re: [go-nuts] [generics] Was "no type contracts" considered?

[Markus Heukelom]

On Mon, Aug 10, 2020 at 8:30 PM Ian Lance Taylor  wrote:

> On Mon, Aug 10, 2020 at 6:07 AM Markus Heukelom
>  wrote:
> >
> > For what it is worth: for non-exported functions/types all operations
> could be allowed, possibly leading to infamous C++-level error messages but
> as you are the author of the package, those error messages would make sense
> to you anyway.
> >
> > For example, I could really use to be able to write things like this:
> >
> > func sibling[type t](node *t) *t {
> > if node.parent == nil {
> > return nil
> > }
> > if node.parent.left == node {
> > return node.parent.right
> >   }
> >   return node.parent.left
> > }
> >
> > This is not really possible with the current design. Of course I could
> specify an interface with getters/setters, but that feels a bit silly and
> cumbersome as everything is local to the package anyway.
> >
> > I don't have better a solution, but all contracts/constraints do is
> prevent long, unreadable error messages while inside a package there's no
> real problem with those error messages to begin with.
>
> Go is a strictly typed languages, and constraints are the meta-types
> of type parameters.


I just realised there might be a distinction between strictly typed and
strongly typed languages. Would it be correct to say C++ is strongly typed,
but not strictly typed wrt templates (up C++20 at least)? Did you mean it
in that sense?

You are suggesting that we should have an escape
> hatch for that meta-type system when using unexported types.  I
> suppose that is possible.  It seems like something we could add later
> if it brings a big benefit.
>
>
I'm not sure when your example would really arise.  It looks like you
> have a tree type; why not make that a parameterized type and make
> sibling a method on the type?
>
>
Mainly for intrusive containers, see for example
https://www.boost.org/doc/libs/1_73_0/doc/html/intrusive.html

In my case I have two multi-index containers that are only used internally.
They use the same rebalancing algorithm and some other stuff for
adding/removing nodes, but I couldn't factor that out with the current
generics design. Well tbh I could define an interface maybe with getters
/setters for the fields but it feels a bit silly for internally used only
stuff. I do agree that it's very niche probably and it does not warrant the
addition of fields to interface constraints.



> Ian
>

-- 
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/CAMoB8rWscmR3vQA5LFHpTPV4KhJzggUszF2HKUA-LoMFNfkoHA%40mail.gmail.com.

Re: [go-nuts] Re: [generics] How to use maps in generic structs?

[Markus Heukelom]

On Mon, Aug 10, 2020 at 8:25 PM Ian Lance Taylor  wrote:

> On Mon, Aug 10, 2020 at 7:08 AM Markus Heukelom
>  wrote:
> >
> > Just a quick thought, instead of "comparable" (and type lists) maybe we
> could use a single operator to specify the required "operators" interface:
> >
> > type BiMap[type V, K ==] struct {
> > forward map[K]V
> > reverse map[V]K
> > }
> >
> > func Max[type T <](a, b T) T {
> >
> > }
> >
> > func ScanRowStruct[type T .](rows sql.Rows, dest *T) error {  //
> operator . ensures T is a struct
> >
> > }
>
> It could probably work, but we wind up with a bunch of special purpose
> syntax with only a tenuous connection to the way constraints work in
> general.  And you have to define connections between operators.  That
> is, comparable supports both == and !=, but you only mentioned ==;
> does == imply !=?
>
>
I would even be in favor of not allowing any operations in generic code on
T (besides what is possible on all types), allowing T to carry data only*.
However, that's admittelly being too restrictive. You really do need to be
able to specify the requirement of ==  to support maps in structs**. No way
around it. The case of "<" is also strong for functions like max etc.

So you could maybe even say: you can specify one operator to use with T and
that's it (not even allowing interface{}-d constraints and not implying
other operators). That's the simplest thing that could possibly make it
work for maps, and most generic algorithms that are really wanted. Of
course "==" and "<" are just shorter ways for "comparable" and "ordered"
and have the slight advantage of not introducing new names in the global
namespace. But both would work.

-Markus

* To me, constraints on T are really complex especially because now you
have to choose whether to just use plain old interfaces or generics with
interface constraints when designing a solution. But being able to use T
instead of interface{} really helps in writing clear and type safe code.
It's the constraints that make it tricky for me.

** Assuming maps don't use !=

Ian
>

-- 
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/CAMoB8rVQNXo242jaU-wMZOdfTscTm-z8OGfys8giytg-BgnSWw%40mail.gmail.com.

Re: [go-nuts] Re: [generics] How to use maps in generic structs?

[Markus Heukelom]

Just a quick thought, instead of "comparable" (and type lists) maybe we
could use a single operator to specify the required "operators" interface:

type BiMap[type V, K ==] struct {
forward map[K]V
reverse map[V]K
}

func Max[type T <](a, b T) T {

}

func ScanRowStruct[type T .](rows sql.Rows, dest *T) error {  // operator .
ensures T is a struct

}




On Mon, Aug 10, 2020 at 3:45 PM 'Carla Pfaff' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> K and V must be comparable, since you use them as map keys:
>
> type BiMap[type V, K comparable] struct {
> forward map[K]V
> reverse map[V]K
> }
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/dwZnPgTC7So/unsubscribe.
> To unsubscribe from this group and all its topics, 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/202f1ffa-ac89-42eb-b617-d82e14c537een%40googlegroups.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/CAMoB8rUUEQPjOejBxX4qY2aYvFUJDJ4%3Da3aXHTWD5fu9QnKgow%40mail.gmail.com.

Re: [go-nuts] [generics] Was "no type contracts" considered?

[Markus Heukelom]

On Sun, Jul 19, 2020 at 3:16 AM Ian Lance Taylor  wrote:

> On Sat, Jul 18, 2020 at 4:55 AM Markus Heukelom
>  wrote:
> >
> > Concerning the current generics proposal, was it every considered to not
> allow type contracts at all?
> >
> > No type contracts would mean that generic functions can only use =, & on
> variables of parametric types, as these are always available for all types.
> Nothings else is allowed.
> >
> > This would remove the possibility to write generic mathematical
> functions, for example. But it is simple and it already enables a lot of
> usefulness. Was this considered too restrictive?
> >
> > Type contracts could optionally be added in a later stage, but at least
> at that point we will have a larger body of generic code to work and test
> with.
> >
> > A bonus, disallowing all operations except assignment and address-taking
> would maybe also stop abuse of templates in the name of "but it is more
> efficient than interfaces" and "fancy coding syndromes".
>
> I think that for a language like Go any generics implementation must
> permit people to write the functions Min and Max.  The functions are
> trivial, but they are among the first that programmers accustomed to
> generics complain about in Go.
>
>
For what it is worth: for non-exported functions/types all operations could
be allowed, possibly leading to infamous C++-level error messages but as
you are the author of the package, those error messages would make sense to
you anyway.

For example, I could really use to be able to write things like this:

func sibling[type t](node *t) *t {
if node.parent == nil {
return nil
}
if node.parent.left == node {
return node.parent.right
  }
  return node.parent.left
}

This is not really possible with the current design. Of course I could
specify an interface with getters/setters, but that feels a bit silly and
cumbersome as everything is local to the package anyway.

I don't have better a solution, but all contracts/constraints do is prevent
long, unreadable error messages while inside a package there's no real
problem with those error messages to begin with.



> Ian
>

-- 
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/CAMoB8rWFa7ifAogg5i0A%3DZbtFAVDwKLX9nh98FyYuxCafKo%2BdQ%40mail.gmail.com.

[go-nuts] [generics] How to use maps in generic structs?

[Markus Heukelom]

This is invalid: 

type BiMap[type V, K] struct {
forward map[K]V
reverse map[V]K 
}

How do I specify an interface constraint for V,K such that this is valid? 
Is that possible at all?


-- 
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/cbd45242-df42-482a-8581-eff882f6e1a8n%40googlegroups.com.

[go-nuts] Question on gofmt and go vet and field tag keys

[Markus Heukelom]

Is there a way to instruct gofmt (or another tool) to reformat field tags 
such that the keys are aligned?

For example:

type Example struct {
Field1 string `json:"x" db:"y"`
Field2 int `json:"ababababc" db:"def"`

Field3 string `json:"zyx" db:"egh"`
Field4 string `json:"z" db:"q"`
}

Would be formatted as

type Example struct {
Field1 string  `json:"x" db:"y"`
Field2 int `json:"ababababc" db:"def"`

Field3 string `json:"zyx" db:"egh"`
Field4 string `json:"z"   db:"q"`
}

(View example in fixed font width please)

Is there a way to instruct go vet (or another tool) to report different 
field tag key order?

For example: 

type Example2 struct {
Field1 string `db:"y" json:"x"`
Field2 int `json:"abc" db:"def"`
}

Would output something along the lines of: "field2: different tag order for 
json and db"

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/53dd5bb1-542e-4adc-96e6-e01608b1b7aan%40googlegroups.com.

Re: [go-nuts] Go 2 review process

[Markus Heukelom]

Would it be an idea to allow people only to label something as proposal if 
they have at least some support / voucher for the idea? Say N>10 general 
upvotes or 1 upvote from a golang committer? 

By allowing the "proposal" label, you sort of give people the idea that 
their idea will be "triaged", to which they then can "appeal". That is in 
fact very generous. Maybe it is better to only allow a "rfc" label (request 
for comments). That way you could post your idea, get feedback from the 
community (including golang fulltimers),  but there's no implied 
expectation whatsoever to the golang fulltimers to give a go/no-go for the 
idea. 


On Friday, July 17, 2020 at 12:36:37 AM UTC+2 Ian Lance Taylor wrote:

> On Thu, Jul 16, 2020 at 1:32 PM Brandon Bennett  wrote:
> >
> > I have just read 
> https://github.com/golang/go/issues/33892#issuecomment-659618902 and 
> since it was posted on a closed issue I wanted to comment a bit more.
> >
> > I subscribed to this issue and read the updates for both the Go2 
> proposals as well as the Go1 proposals and I enjoy reading them. I 
> understand the reasoning behind wanting to do less here but I do belive 
> there are some downsides as well.
> >
> > One reason I read these every week is that it gives people outside of 
> the Go team an insight into the thought process and the reasoning of 
> decisions. Also feedback on these changes hopefully should help to refine 
> future requests. I am really afraid that just "ignoring" requests continues 
> or goes back to the idea that that Go is not a community language and that 
> the only ideas and changes can come from Google employees (or past 
> employees in the case of bradfitz). The transparency here was awesome and I 
> am very sad to see it go away.
> >
> > I hope there is some other middle ground or at least some details around 
> what will go into hand picking? For the non-picked proposals will they just 
> remain open for some undetermined amount of time? Will they just be closed? 
> Is feedback on these still expected? Maybe the real solution is just to 
> meet up less? Maybe once a month or even once a quarter vs every week?
>
>
> I think one way to describe what is happening is our growing awareness
> over time that most language change proposals don't bring enough
> value. The language is stable and is not looking to change in any
> significant way (except perhaps for adding generics). We've realized
> that we need to be upfront about that. What has been happening with
> language change proposals is that we say we don't see enough value,
> but naturally the proposer does see value, and often is not happy
> about our comments. Then we get into an uncomfortable discussion
> where we say no and the proposer says why not. This leads to hurt
> feelings and no useful progress, and we certainly don't feel good
> about it ourselves. For example, just to pick on one perhaps
> unfairly, see https://golang.org/issue/39530.
>
> I agree that feedback should ideally help to refine future requests,
> but after a couple of years of feedback I see no evidence that that is
> happening. Maybe our feedback is bad, but I also suspect that part of
> the problem is that most people who want to suggest a language change
> don't read the earlier feedback. Or perhaps the ones who do just
> don't go on to propose a change after all. I can certainly understand
> not reading all the feedback; there are 89 issues just on the topic of
> error handling alone, some of them quite long. But it follows that I
> can understand that the feedback isn't helping much.
>
> This doesn't mean that there will be some other process for making
> language changes. It's still the same process. There is no special
> route for Google employees (and most proposals by Google employees are
> rejected, just like most proposals by non-Google-employees). What it
> means, I hope, is that more changes will be rejected more quickly and
> with less back and forth discussion.
>
> One observation that led to this change is that often we would look at
> a proposal and immediately say "well, this one is not going to be
> accepted." But then it would take us 30 minutes to explain why, and
> then we would spend another few hours over the next few weeks replying
> to comments. But the fact was we knew in 30 seconds that it wasn't
> going to be accepted. It may sound blunt, but I think it will be a
> net benefit to the overall ecosystem to spend just 1 minute on that
> kind of proposal, not several hours over time.
>
> Hope this helps. Happy to hear comments.
>
> Ian
>

-- 
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/29cad39d-caa3-4315-bedc-bea3a02dc10dn%40googlegroups.com.

Re: [go-nuts] [generics] Was "no type contracts" considered?

[Markus Heukelom]

I complained myself too about not being able to write a generic Min, Max, 
but  I am not so sure anymore myself of the strength of this argument.

The point is: besides Min and Max, what other really good, general, 
examples are there of really missing?

To give an example myself,  I'd love to write

func (type T) SliceContains(list []T) bool 

Turns out, it was 99% always strings in my case! Maybe 100%. So I really 
didn't need it. I *thought* I needed it, but I just wanted to be fancy and 
write it for all types. Besides like you also said most of these functions 
are really really trivial to write quickly. I have MaxInt in several 
packages.

What we do undoubtedly need generics for is better type safety in generic 
data structures and (channel algorithms maybe). Generic (math) algorithms 
are very powerful too, I personally would love to have them, but could 
"delayed" or even decided to be never allowed to protect from "fancy 
template coding". It would certainly protect me from the latter.

So I am not saying Max(T) should be never supported, but generics would 
already be very useful without and it simplifies the design process a lot 
(if care is taken that it could reasonably added later).

It's just something that could be considered. 

-Markus




On Sunday, July 19, 2020 at 3:17:07 AM UTC+2 Ian Lance Taylor wrote:

> On Sat, Jul 18, 2020 at 4:55 AM Markus Heukelom
>  wrote:
> >
> > Concerning the current generics proposal, was it every considered to not 
> allow type contracts at all?
> >
> > No type contracts would mean that generic functions can only use =, & on 
> variables of parametric types, as these are always available for all types. 
> Nothings else is allowed.
> >
> > This would remove the possibility to write generic mathematical 
> functions, for example. But it is simple and it already enables a lot of 
> usefulness. Was this considered too restrictive?
> >
> > Type contracts could optionally be added in a later stage, but at least 
> at that point we will have a larger body of generic code to work and test 
> with.
> >
> > A bonus, disallowing all operations except assignment and address-taking 
> would maybe also stop abuse of templates in the name of "but it is more 
> efficient than interfaces" and "fancy coding syndromes".
>
> I think that for a language like Go any generics implementation must
> permit people to write the functions Min and Max. The functions are
> trivial, but they are among the first that programmers accustomed to
> generics complain about in Go.
>
> Ian
>

-- 
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/ef98d09e-b11c-47ed-9c15-f16ec39dad3an%40googlegroups.com.

Re: [go-nuts] [generics] question regarding package level generic type declarations

[Markus Heukelom]

If you need different type parameters lists, use multiple groups:

package collection

generic (type T) (

type List struct {
root *Node(T)
}

type Node struct {
prev, next *Node(T)
}

func (l *List(T)) InsertAfter(after* Node(T))
)

generic (type T1, T2) (
MapList(l List(T1), mapFn func(value T1) T2) List(T2)
ReduceList(l List(T1), init T2, accFn func(cur T2, val T1) T2) T2
)

generic (type T) Add(a, b T) { // not grouping is also allowed of course
}

func TestStuff() {
myMap := BiMap(int,string) // personally I really see the point in using <> 
or [] as this looks like a function call
myList := LinkedList(float64)
}
Syntax is a sketch. Please don't get me on "generic" key word etc :) it's 
not the point here.

Indentation: don't think there is a major issue here, it can just be 
indented. Indentation is automatically done anyway by most setups anyway. 
Or we don't indent. As long as it is consistent and automatic.

I think the grouping is could also especially helpful in the documentation, 
to get rid of redudant "noisy" type parameter lists.  

On Sunday, July 19, 2020 at 3:15:12 AM UTC+2 Ian Lance Taylor wrote:

> On Sat, Jul 18, 2020 at 4:00 AM Markus Heukelom
>  wrote:
> >
> > Concerning only the current proposal, is there a reason why we shouldn't 
> allow specifying the parametric types for a whole bunch of functions / 
> types at once?
> >
> > Like:
> >
> > generic (type T) (
> >
> > func Average(value []T) {...}
> > func Median(value []T) {...}
> > // etc
> > )
> >
> > generic (type T1, T2) (
> >
> > func Map(s []T1, func(T1) T2) []T2
> > func BiMap(s []T1, func(T1) T2) []T2
> > //...
> > )
> >
> >
> > All things within generic () would have the same type parameter 
> signature. It would be a bit similar to how var and const declarations 
> work. It would remove a lot of redundancy and parenthesis.
> >
> > To make things symmetric, a single generic function would have to be 
> specified with something like this
> >
> > generic (type T1, T2) func Map(s []T1, func(T1) T2) []T2.
> >
> > type Vertex generic (type T) struct {
> > Coords [3]T
> > }
>
>
> How do we instantiate these generic types and functions? If a list of
> generic type parameters is factored out, do we have to supply all of
> them even if a particular function only uses one of them?
>
> Also, while this may seem like a trivial question, how do we indent
> within a generic block?
>
> (To answer your question, we did actually look at syntactic approaches
> along these lines for a while, but we eventually moved on to the ideas
> presented in the design draft. Not because this idea is terrible, but
> because we felt the approach used in the design draft was a better fit
> for the language.)
>
> Ian
>

-- 
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/965f6d83-0384-48b9-a216-4d83d47an%40googlegroups.com.

[go-nuts] [generics] Was "no type contracts" considered?

[Markus Heukelom]

Concerning the current generics proposal, was it every considered to not 
allow type contracts at all?

No type contracts would mean that generic functions can only use =, & on 
variables of parametric types, as these are always available for all types. 
Nothings else is allowed.  

This would remove the possibility to write generic mathematical functions, 
for example. But it is simple and it already enables a lot of usefulness. 
Was this considered too restrictive?

Type contracts could optionally be added in a later stage, but at least at 
that point we will have a larger body of generic code to work and test 
with. 

A bonus, disallowing all operations except assignment and address-taking 
would maybe also stop abuse of templates in the name of "but it is more 
efficient than interfaces" and "fancy coding syndromes".

-Markus

-- 
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/60e96044-e8ca-46de-a5cd-7004ece3be7bn%40googlegroups.com.

Re: [go-nuts] [generics] question regarding package level generic type declarations

[Markus Heukelom]

Thanks for the answer.

Concerning only the current proposal, is there a reason why we shouldn't
allow specifying the parametric types for a whole bunch of functions /
types at once?

Like:

generic (type T) (

func Average(value []T) {...}
func Median(value []T) {...}
// etc
)

generic (type T1, T2) (

func Map(s []T1, func(T1) T2) []T2
func BiMap(s []T1, func(T1) T2) []T2
//...
)


All things within generic () would have the same type parameter signature.
It would be a bit similar to how var and const declarations work. It would
remove a lot of redundancy and parenthesis.

To make things symmetric, a single generic function would have to be
specified with something like this

generic (type T1, T2) func Map(s []T1, func(T1) T2) []T2.

type Vertex generic (type T) struct {
 Coords [3]T
}

On Fri, Jul 17, 2020 at 8:26 PM Ian Lance Taylor  wrote:

> On Fri, Jul 17, 2020 at 1:56 AM Markus Heukelom
>  wrote:
> >
> > The authors of the current generics proposal mention that they looked
> into doing generics only on package level:(
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-put-type-parameters-on-packages
> )
> >
> > I understand the reasons what it wasn't pursued further.
> >
> > Did the authors investigate the possibility of declaring generic types
> on a package level instead of per type/function? Ie.
> >
> > generic T {}
> >
> > func Max(a, b T) T {}
> > func Min(a, b T) T {}
> >
> > I wrote down an idea on this, that is admittingly a bit wild (or naive)
> or maybe impossible from a parsing perspective. But I'd like to validate
> the main idea behind it.
> >
> > My whole attempt was based on the observation that most packages that
> will include generic functionality, will only really need one or maybe a
> couple of generic type constraints.
> >
> > For example, if you look at a hypothetical statistics package, there
> will be many, many functions that compute stuff on slices of T, where T
> must be a number. So there will be many functions like:
> >
> > type Number interface { // using currently proposed generics
> > type int, float64, // etc
> > }
> >
> > func Average(type T Number)(values T...) T {} // using currently
> proposed generics
> > func Median(type T Number)(values T...) T {}
> > func Binonimal(type T Number)(values T...) T {}
> > // etc etc etc
> >
> > My point is that the "(type T Number)" part in all the declarations /
> definitions become really redundant from a human perspective, just because
> a package will naturally (should?) only use 1 or at most a couple of
> generic types. That would make it, at least theoretically, possible to
> write something like
> >
> > type Number interface {
> > int, float64, // etc
> > }
> > generic T Number
> >
> > func Average(values T...) T {}
> > func Median((values T...) T {}
> > // etc
> >
> > Coincidentally, the builtin language sort of uses this idea in its
> documentation.
> >
> > Another (theoretic) possibility would be something like this:
> >
> > generic T Number ( // analog to multiple const or var declarations
> > func Average(values T...) T {}
> > func Median((values T...) T {}
> > )
> >
> > My question is: did the authors investigate something like this, or is
> it plainly impossible or undesired?
> >
> > For those interested, my proposal can be found here:
> https://github.com/golang/go/issues/39716. I use the key word "meta"
> there instead of "generic".
>
> Thanks for the note.
>
> Yes, we looked at ideas like that.  It's unclear how to handle this
> area at the point where we want to instantiate the generic function or
> type.  How do we pass the type argument?  If there is a single generic
> type parameter it's not so bad, but there are many simple examples
> that require multiple type parameters, such as the Map function on
> slices:
>
> func Map(type T1, T2)(s []T1, func(T1) T2) []T2
>
> There should be some natural way for the caller to write Map(int,
> string) to get a value whose type is
>
> func([]int, func(int) string) []string
>
> If generics are defined at the package level, how do we do that?
>
> If the answer is that you specify the type arguments when you import
> the package, then how do handle List(List(int))?
>
> Ian
>

-- 
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/CAMoB8rVSU%2B1vbrZ9QiUjs7vBc4KbiddiaKyvv3b1M4TXb%3DL58w%40mail.gmail.com.

[go-nuts] [generics] question regarding package level generic type declarations

[Markus Heukelom]

The authors of the current generics proposal mention that they looked into 
doing generics only on package level:(
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-put-type-parameters-on-packages
)

I understand the reasons what it wasn't pursued further. 

Did the authors investigate the possibility of declaring generic types on a 
package level instead of per type/function? Ie.

generic T {}

func Max(a, b T) T {}
func Min(a, b T) T {}

I wrote down an idea on this, that is admittingly a bit wild (or naive) or 
maybe impossible from a parsing perspective. But I'd like to validate the 
main idea behind it. 

My whole attempt was based on the observation that most packages that will 
include generic functionality, will only really need one or maybe a couple 
of generic type constraints. 

For example, if you look at a hypothetical statistics package, there will 
be many, many functions that compute stuff on slices of T, where T must be 
a number. So there will be many functions like:

type Number interface { // using currently proposed generics
type int, float64, // etc
}

func Average(type T Number)(values T...) T {} // using currently proposed 
generics
func Median(type T Number)(values T...) T {} 
func Binonimal(type T Number)(values T...) T {} 
// etc etc etc

My point is that the "(type T Number)" part in all the declarations / 
definitions become really redundant from a human perspective, just because 
a package will naturally (should?) only use 1 or at most a couple of 
generic types. That would make it, at least theoretically, possible to 
write something like

type Number interface {
int, float64, // etc
}
generic T Number

func Average(values T...) T {}
func Median((values T...) T {} 
// etc

Coincidentally, the builtin language sort of uses this idea in its 
documentation.

Another (theoretic) possibility would be something like this:

generic T Number ( // analog to multiple const or var declarations
func Average(values T...) T {}
func Median((values T...) T {} 
)

My question is: did the authors investigate something like this, or is it 
plainly impossible or undesired?  

For those interested, my proposal can be found here: 
https://github.com/golang/go/issues/39716. I use the key word "meta" there 
instead of "generic".

-- 
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/245ce96d-52e4-4763-9296-58b8fdf26b1bn%40googlegroups.com.

Re: [go-nuts] [generics] Data structures and the garbage collector

[Markus Heukelom]

> Many data structures are implemented using pointers. How does this perform 
>> wrt garbage collecting? For example take any data structure that uses some 
>> tree of nodes, or even simpler just a singly linked list: there is one 
>> pointer from the left node to the next. Wouldn't this incur huge GC 
>> (unavoidable) cycles for large linked lists that will look at all pointers? 
>> I can imagine that a large AVL tree would then cause potentially large 
>> hick-ups in the GC cycle? 
>>
>>
> Is your worry latency in the form of pause times while doing GC, or 
> bandwidth in the form of CPU cycles when doing GC? It isn't entirely clear.
>
>
My "worry" is about CPU cycles that would not be (necessarily) needed in 
let's say C++ or C. The fact that Go has a concurrent GC resulting in no 
"stop the world"-hick-ups is really awesome, but was not my main point. 

(btw I don't really "worry" about it for any real applications; it was more 
a question out of interest)

The reason I asked is because I use a custom tree data-structure that 
manages parent-child, and leaf node prev-next, relationships using 
pointers. I use the tree for multiple value types, so the payload type is 
interface{} now. It would be a great place for me to use generics; this 
would make my code more clear and safer. 

In any case, you are right that these things require attention in a garbage 
> collector, both of them. But Go has addressed this for many years now.
>
> As an example, imagine you have a binary AVL or Red/Black tree taking up 
> 128 Gigabyte of memory space. You now delete the root node of said tree.
>
> Example 1: in C++ we have reference counted the tree. Deleting the root 
> node sets its childrens refcounts to 0, so they get deleted, and so on 
> recursively down the tree. It might take some time to delete 128 Gigabyte 
> of data this way. So C++ isn't exempt from memory reclamation pauses either.
>
>
In C/C++ you could better use an arena-allocator and not refcounts. 
Clearing the tree would then use only (nodes / (nodes per region)) 
deallocation calls. As the region is typically large, this would probably 
be orders of magnitude quicker. I believe compilers use arena allocators 
for this reason. (Deleting individual nodes would be cheaper maybe as 
well.) 

Refcounting I think is best reserved for situations where the lifetime of 
an object is not determined by, or escapes, the package (class internals in 
C++), or for reasons  of simplicity of implementation of course.

I was under the (false) impression that one of the reasons of having a 
built-in array, slice and map type in Go (besides it just being really 
handy) is that for example a map[string]int would relieve the GC needing to 
trace the keys and values (in contrast to for example map[int]*string). But 
apparently (see Ian's answer) this is not the case, and the GC always needs 
to trace all elements, keys and values. In that case there is (luckily) no 
reason to choose build-in map over a custom map written with generics.
 

> Example 2: Imagine a language using Cheney's copying collection as the 
> main garbage collection scheme. It will use 256 gigabyte of memory for its 
> two copying spaces, but collection time will be 0, since the tree's data 
> isn't live. You are paying with memory for faster collection in this case.
>
> Example 3: Concurrent collectors, like the one Go uses nowadays, will 
> collect the tree while the program is running and doing productive work. 
> While doing so incurs a bandwidth loss, latency pause times do not suffer. 
> If you have spare CPU cores, they'll be used to handle the collection while 
> the remaining cores run the program (more or less, this is a gross 
> simplification).
>
> As for generics:
>
> When you use a generic, you substitute in a type to generate a 
> special-case of a function for that type. If the implementation uses 
> monomorphization, it will generate a new piece of code specifically for 
> that type invocation. This might mean other optimizations trigger for the 
> code path, notably stripping pointers away.
>
> As for general worry:
>
> In some cases it is beneficial to construct data structures such that they 
> pack data well and don't use excessive amounts of pointers. One reason is 
> that collecting pointers takes time in any language. Another reason is that 
> pointer indirections cost memory loads, which can be expensive. A third 
> reason is that packed data has cache locality, so access to data close 
> together is several orders of magnitude faster than following yet another 
> pointer indirection. And finally, it might avoid memory pressure in copying 
> data around.
>
>

-- 
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] [generics] Data structures and the garbage collector

[Markus Heukelom]

Hi,

Many data structures are implemented using pointers. How does this perform 
wrt garbage collecting? For example take any data structure that uses some 
tree of nodes, or even simpler just a singly linked list: there is one 
pointer from the left node to the next. Wouldn't this incur huge GC 
(unavoidable) cycles for large linked lists that will look at all pointers? 
I can imagine that a large AVL tree would then cause potentially large 
hick-ups in the GC cycle? 

Of course, luckily we have map where you can just store the values. But if 
people start using generics for their own map types, or trees, wouldn't 
this potentially be a bigger problem? Wouldn't this defy the use of 
generics for data structures aimed to manage a lot of data?

I don't know how Java does this for example, or if it is no practical issue 
at all. In C++ you can you ref counting for the nodes, in C you would use a 
arena allocator probably for the nodes etc. I was wondering how this 
relates to Go.

-Markus






-- 
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/942ebe05-2bd8-4fc2-bed7-b7d90518fd6fn%40googlegroups.com.