Re: [go-nuts] Data race in sql package

[Michal Hruby]

That's right, atm there's no safe way to use sql.RawBytes, it should either
be documented that you need to manually control the context, or the
standard library shouldn't be closing the driver.Rows unless the user calls
Scan or Close.

On Fri, 22 Jul 2022, 00:45 Steven Hartland,  wrote:

> I'm guessing that Michal is flagging is there no way to write safe code if
> your using stmt.QueryContext(ctx) and rows.Scan into a sql.RawBytes
> as QueryContext kicks off a go routine that monitors the ctx, closing rows
> if cancelled and that ctx can be cancelled at any time.
>
> The only thing that springs to mind is to only allow the cancellation
> processing to happen while in sql functions which would mean that
> sql.RawBytes can't be updated while the consumer, user code, is processing
> it.
>
> It's interesting that there is a related comment in row.Scan
> <https://github.com/golang/go/blob/176b63e7113b82c140a4ecb2620024526c2c42e3/src/database/sql/sql.go#L3356>,
> which prevents the use of sql.RawBytes because it always closes the
> underlying rows before returning.
>
> On Thu, 21 Jul 2022 at 20:02, Ian Lance Taylor  wrote:
>
>> On Thu, Jul 21, 2022 at 11:02 AM Michal Hruby 
>> wrote:
>> >
>> > Hello, I have a code snippet equivalent to this one:
>> >
>> > rows, err := stmt.QueryContext(ctx)
>> > if err != nil {
>> > return info, nil, err
>> > }
>> > defer rows.Close()
>> >
>> > var data sql.RawBytes
>> > for rows.Next() {
>> > err = rows.Scan()
>> > if err != nil {
>> > return nil, err
>> > }
>> > // if ctx is canceled around this point, rows.Close() will be
>> called and the data can e overwritten, causing a data race
>> > _ = data[0] // <--- possible concurrent read here and write inside
>> driver.Rows.Close()
>> > }
>> >
>> > And as the comments say, if the context is cancelled, there's a
>> possibility of a data race where this goroutine is trying to read data[0],
>> and another goroutine can be writing to it, cause the sql package calls
>> driver.Rows.Close() (from
>> https://github.com/golang/go/blob/176b63e7113b82c140a4ecb2620024526c2c42e3/src/database/sql/sql.go#L2974
>> )
>> >
>> > I've opened an issue about this on github (
>> https://github.com/golang/go/issues/53970 ), but was told that's not the
>> proper forum to talk about data races.
>> >
>> > Any help would be appreciated, thanks.
>>
>> I don't quite understand what you are asking.  I think you're correct
>> that there is a data race there.  It seems to me that the answer is to
>> not cancel the context.
>>
>> What kind of answer are you looking for?
>>
>> 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/CAOyqgcUwGN5b-DEwCqLRu6kWwpAnCvO7o6u5TjzS3bmbUgksdw%40mail.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/CAFpGN7-turpYxZ87EY4EaA9aYYcpEzwxs8rCKQwGG%3Dr5FBCY1Q%40mail.gmail.com.

[go-nuts] Data race in sql package

[Michal Hruby]

Hello, I have a code snippet equivalent to this one:

rows, err := stmt.QueryContext(ctx)
if err != nil {
return info, nil, err
}
defer rows.Close()

var data sql.RawBytes
for rows.Next() {
err = rows.Scan()
if err != nil {
return nil, err
}
// if ctx is canceled around this point, rows.Close() will be called 
and the data can e overwritten, causing a data race
_ = data[0] // <--- possible concurrent read here and write inside 
driver.Rows.Close()
}

And as the comments say, if the context is cancelled, there's a possibility 
of a data race where this goroutine is trying to read data[0], and another 
goroutine can be writing to it, cause the sql package calls 
driver.Rows.Close() 
(from 
https://github.com/golang/go/blob/176b63e7113b82c140a4ecb2620024526c2c42e3/src/database/sql/sql.go#L2974
 
)

I've opened an issue about this on github ( 
https://github.com/golang/go/issues/53970 ), but was told that's not the 
proper forum to talk about data races.

Any help would be appreciated, 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/6c0345cb-5e39-4db0-90c8-6cab97d0f0ean%40googlegroups.com.

[go-nuts] Ambiguous Method Promotion Bug?

[Michal Ostrowski]

Here is a playground doc that demonstrates what seems to be strange 
behavior regarding promotion of methods.

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

It seems that I can generate a struct a have an ambiguous method by adding 
a level of indirection in struct definitions.  Or there's something in the 
language spec that I'm missing (and I'd appreciate a reference to that in 
that case.)



-- 
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/cb606644-1b76-4db1-af8c-96b5efac1c20n%40googlegroups.com.

[go-nuts] Thoughts on the try proposal (and Generics)

[Michal Bohuslávek]

I've been thinking a lot about this Russ's comment 
 from the 
try
proposal:

> But before we get to try, it is worth making sure we're all on the
> same page about appropriate error context. The canonical example
> is os.Open. Quoting the Go blog post “Error handling and Go”:
>
> > It is the error implementation's responsibility to summarize the
> > context.  The error returned by os.Open formats as "open /etc/passwd:
> > permission denied," not just "permission denied."
>
> See also Effective Go's section on Errors.

Specifically, this quote:

> There is lots of code following the Go convention today, but there
> is also lots of code assuming the opposite convention. It's too
> common to see code like:
>
> f, err := os.Open(file)
> if err != nil {
> log.Fatalf("opening %s: %v", file, err)
> }

I'd say, from the comments on the try proposal and other proposals
related to error handling, as well as from various different blog posts
and podcasts, that there's more cases that follow the *opposite*
*convention*, i.e. it is the caller rather than the implementation that is
adding context.

Most functions are called more than once in a program, so adding
context to the implementation itself would benefit every caller: they don't
need to add the context themselves.

This brings me back to the try proposal, which, as far as I know,
was trying to solve the most common problem: removing boiler plate
code when the caller has no additional context to add. In my estimate,
this is roughly 50 % of the cases in a typical codebase. A number
of commenters were arguing that the try proposal doesn't make it
easier to add context to the error, but that wasn't the problem it
was trying to solve. It's already quite easy to add context on the
caller's side: just use if/switch statements or other mechanisms.
(Errors are values.)

So despite being sceptic at first, I ended up being in support of
the try proposal. It solves the biggest issue with error handling,
and it solves it well. Specifically it:

1. encourages the right convention to add context on the callee's side,
2. and makes the code more clear and expressive for roughly 50 % of the 
cases.

In my view, the only valid arguments against this proposal were outlined in 
the
decline comment 
 by 
Robert:

> As far as technical feedback, this discussion has helpfully identified
> some important considerations we missed, most notably the implications
> for adding debugging prints and analyzing code coverage.

As I see it, the first step in the journey to better error handling
is to make most Go code agree on which convention to use: whether
it is the implementation, or the caller who is responsible for adding
context.



Since the recent changes to the Generics proposal make it more
realistic that Go might one day get generics, I was thinking whether
the try proposal could be implemented using them. This is what I
come up with:

// Package eh implements functions for error handling.
package eh

func Check(err error) { … }

func Try[type T](v T, err error) T { … }

func Try3[type T, U](v T, w U, err error) (T, U) { … }

func Catch(errp *error) { … }

func Catchf(errp *error, format string, args ...interface{}) { … }

1. First off, the package name should be short since the package
   would be used a lot in practice.
2. We don't need that many variants for the different argument
   counts: most functions returning errors return 2 values. There might
   be some with 3 values. We might add Try4 or even Try5 if that would
   prove to be useful.
3. The name Check seemed to fit better for error-only checking.
4. In order for this to work the package would need to use panic;
   thus, every function using this kind of error handling would *need*
   to defer calling to either Catch or Catchf. This would probably
   require some sort of vet check to prevent misuse.
5. This package combines variants of the proposed built-in function
   "try" as well as the helper methods as proposed by Russ in
   https://github.com/golang/go/issues/32676. I chose Catch and Catchf
   without further consideration; that's not the point of this post.

Some examples derived from the try proposal:

func CopyFile(src, dst string) (err error) {
defer eh.Catchf(, "copy %s %s", src, dst)

r := eh.Try(os.Open(src))
defer r.Close()

w := eh.Try(os.Create(dst))
defer func() {
w.Close()
if err != nil {
os.Remove(dst)
}
}()

eh.Try(io.Copy(w, r))
eh.Check(w.Close())
return nil
}

func printSum(a, b string) (err error) {
defer eh.Catch()
x := eh.Try(strconv.Atoi(a))
y := eh.Try(strconv.Atoi(b))
fmt.Println("result:", x+y)
return nil
}

There are really 2 questions I want to ask:

1. How to motivate people to use the Go convention (let the
   

Re: [go-nuts] Generics and parentheses

[Michal Strba]

Very correct! At least from my perspective.

On Thu, 23 Jul 2020 at 02:02 Russ Cox  wrote:

> So it sounds like everyone is in favor of the entire generics proposal and
> all the semantics, and all we have left to hammer out is the bracket
> characters? Do I have that right?
>
> Best,
> Russ
>
>
>
> --
> 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/7t-Q2vt60J8/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/CAA8EjDRrEBeOgs2Yax%2BgtHp-oJqCApjGJJEsop-S1OzOJbU3xA%40mail.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/CAO6k0usy2JKtkKgtkfNeveLv9X%2B7YiO0mjHbna2o%2B5ef4%2BRBow%40mail.gmail.com.

Re: [go-nuts] Re: Generics and parentheses

[Michal Strba]

Thanks for the feedback Ian! I was drawing the idea mostly from Rust, which
already does the same thing, but uses "::" instead of a dot and it works
fine there, but sure, it has its drawbacks.

st 22. 7. 2020 o 0:05 Ian Lance Taylor  napísal(a):

> On Tue, Jul 21, 2020 at 8:49 AM  wrote:
> >
> > I feel like you guys missed my suggestion earlier. I will repeat it
> because I think it can be good. What about a dot to separate type
> parameters in specialization?
> >
> > func zero() T {
> > var x T
> > return x
> > }
> >
> > func main() {
> > fmt.Println(zero.()) // . required here
> > }
> >
> > Dot would be required in expressions when type parameters cannot be
> inferred and need to be specified manually.
> >
> > I believe this fixes the syntactic ambiguities and also is consistent
> with the type assertion syntax.
> >
> > What do you think?
>
> Thanks for the note.  I did see the earlier suggestion.
>
> Speaking personally, I think the advantage of angle brackets is that
> some other languages, notably C++ and Java, use them for type
> parameters.  But they use F, not F..  While I see the
> advantage of emulating the C++ and Java syntax for type parameters, I
> don't see the advantage of having a different syntax that is similar
> but not identical.  In my opinion, a similar but different syntax is
> either no better than a more different syntax, or it is actually worse
> because people will keep accidentally typing F when they meant to
> type F..  So I don't see the advantage of ..
>
> You mention the type assertion syntax, but that vague similarity seems
> like another minor drawback, since this syntax would be used for
> instantiation, which is nothing like type assertion.
>
> Just my personal opinion, of course.
>
> 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/CAO6k0utWCFeNk2fC0X8ZzGH2hSVWFz-iRTR%3DZj%3DS%2BSjHvBwc%3Dw%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[Michal Strba]

I'd say a dot is necessary when instantiating a function call but
unnecessary when instantiating a type because it's always syntactically
clear when a type is required.

ut 21. 7. 2020 o 18:51  napísal(a):

> Using angle brackets is not a must for supporting generics, but it is the
> common syntax of generics in programming languages that support generics,
> the same way as square brackets are the common syntax for indexing in
> programming languages.
>
> If I understand correctly, the ambiguity problem with angle brackets
> appears only at instantiation, so if we prefixed all the angle brackets
> occurrences with a dot(.) that ambiguity would gone.
>
> Although prefixing the angle brackets with a dot(.) in all occurrences is
> not required and maybe removed from some places and/or be required only for
> instantiation.
>
> The common use for the dot(.) in programming languages is to access some
> field or property of the entity it's called on, and that would be the
> same(in instantiation case), cause we would be accessing the specific
> function, or the specific type of the generic function or the generic type,
> respectively, so that common understanding about the dot(.) would still
> hold, in my opinion.
>
> If I understand correctly(and please correct me if I am wrong) the dot(.)
> in that approach doesn't introduce any ambiguity and would require only one
> lookahead(to see if the following char is the left angle bracket or not),
> so it should be acceptable.
>
> example:
>
> package list
>
> type List. struct {  // the dot(.) maybe remove here
> // some code
> }
>
> type FloatList List.  // the dot(.) has to exist here
>
> func NewList.() (list List.) {  // the dot(.) maybe remove here
> // some code
> }
>
> func NewListFrom.(arr []E) (list List.) {  // the dot(.) maybe
> remove here
> // some code
> }
>
> func(l List.) Add(newElem E) {  // the dot(.) maybe remove here
> // some code
> }
>
> package main
>
> func main() {
> l := list.NewList.()  // the dot(.) has to exist here
> l.Add(1)
> var arr []int
> intList := list.NewListFrom(arr) // type inference is done here,
> so the dot(.) doesn't exist here
> }
>
> --
> 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/7t-Q2vt60J8/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/0b206c05-e10c-48a4-b641-cb29209b9df5o%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/CAO6k0uu8hE2MmavFUjVZALkxPEYPTOr10Cp%3DYj6oE0%2BOt1GEQw%40mail.gmail.com.

Re: [go-nuts] Re: Generics and parentheses

[Michal Strba]

Angle brackets are only problematic in expressions in the bodies of
functions when specializing a function or a type, right? They are not
problematic in signatures and type definitions.

What about using a dot when specializing in bodies?

func zero() T {
var z T
return z
}

func main() {
x := zero.() // requires a dot
}

This is less weird than it looks, because Go already uses a dot for type
assertions and this is a similar thing.

On Wed, 15 Jul 2020 at 05:39 Ian Lance Taylor  wrote:

> On Tue, Jul 14, 2020 at 8:31 PM  wrote:
> >
> > One way to distinguish between type A[N] E and type A [N]E is to be more
> space-sensitive and, for example, disallow whitespace between a type name
> and the opening square bracket when it signifies type parameters.
>
> I would be extremely reluctant to make the syntax depend on invisible
> whitespace.  The syntax already depends on line breaks, but at least
> line breaks are very visible.  Spacing within a line can be hard to
> see and it would be quite easy to make mistakes.
>
> 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/CAO6k0uuAqy2kgvEWYL%2BRxhMgjW7rQi8pCaORuaauSWjmb_Mq%2BA%40mail.gmail.com.

Re: [go-nuts] A better io.Reader.Read signature?

[Michal Strba]

Your proposed signature has a little problem and that is that when calling

result, err := reader.Read(nil)

the Read method doesn’t know how many bytes it should read.

The incoming buffer parameter actually serves two purposes. First is to
provide a place for storage. The second is to tell how many bytes should be
read.

If you want to read all the bytes from a reader, you can use
https://golang.org/pkg/io/ioutil/#ReadAll

If you want to read N bytes into a freshly allocated buffer, you can make a
helper function:

func ReadNBytes(r io.Reader, n int) (result []byte, err error) {
result = make([]byte, n)
n, err := r.Read(result)
return result[:n], err
}

On Fri, 6 Sep 2019 at 00:48 Tom Payne  wrote:

> Dave Cheney has written (yet another) excellent blog post on Go, on the
> subject of API design and caller-controlled allocations:
>
> https://dave.cheney.net/2019/09/05/dont-force-allocations-on-the-callers-of-your-api
>
> In this he compares two possible signatures for the io.Reader.Read method:
>   func (r *Reader) Read(buf []byte) (int, error)
>   func (r *Reader) Read() ([]byte, error)
> and makes a very good case for why the first, albeit trickier to use, is
> the better API. The post also sets up a false dichotomy/straw man argument,
> comparing only two signatures when there are other alternatives too.
>
> What about the following API:
>   func (r *Reader) Read(buf []byte) (result []byte, err error)
> If the buf argument is non-nil then buf is used to store the result,
> len(result) == the int returned by the actual Read(buf []byte) (int, error)
> method.
> If the buf argument is nil then a new []byte is created and returned, i.e.
> the allocation is done by Read and the method is as easy to use as Read()
> ([]byte, error).
> The semantics of the error return remain the same (i.e. Read might return
> both some bytes read and an error), but that is orthogonal to the memory
> allocation.
> An example of this pattern is here
> .
>
> Given that slices are small and cheap to copy (a pointer to the data, a
> length, and a capacity) what are the downsides to using
>   func (r *Reader) Read(buf []byte) (result []byte, err error)
> as a method?
>
> I am not suggesting that we change io.Reader (that would break
> everything!), just looking for input into good Go API design.
>
> This would be a comment on Dave's fantastic blog, but the blog does not
> have comment functionality, so I'm asking here, and I know that Dave lurks
> here too.
>
> Cheers,
> Tom
>
> --
> 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/8ffb9828-c6e2-47de-bca1-ef6988f081e8%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/CAO6k0uvEZgHm9ppQ8sA1K-M8fA2WENf0tJG1KyTov7PXAt6GcQ%40mail.gmail.com.

Re: [go-nuts] VSCode

[Michal Strba]

Why do you need to modify the .bashrc file? All I did was to install the Go
extension and everything else proceeded either automatically or through a
few dialog boxes.

On Tue, 27 Aug 2019 at 14:40 Andreqx  wrote:

> I am trying to install VSCode to run with Go. I Need to modify the
> /.bashrc file. Could somebody pleas let me know what statements to add, as
> every thing to date hasn't worked.
> Thank you
>
> --
> 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/0ff1c574-7d98-4489-b932-108cdc69745c%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/CAO6k0usQDChMVFNggBRnKRS76Yd%3DNresOtazm8Rmr_5mnY67jg%40mail.gmail.com.

Re: [go-nuts] Re: About the Google logo on the new Go website

[Michal Strba]

Guys, why not keep the discussion to the point. Oracle is quite irrelevant
here. The issue is the perception of Go among programmers.

On Wed, Jul 17, 2019, 11:46 Wojciech S. Czarnecki  wrote:

> On Tue, 16 Jul 2019 23:06:41 -0700
> Michael Jones  wrote:
>
> > In regards to Oracle, I was delighted when they released   under GPL
> > and remain delighted that they pay Oracle employees to enhance it
> > and share their work.
>
> Excuse me?!
>
> 1. VirtualBox was opensourced under GPL by its real creators, the Innotek
> GmbH.
>
> 2. Even before that, VirtualBox was available under so called PUEL license
> first
> to developers then also to SMEs -- i.e. to everyone that made install by
> him or herself.
>
> 3. VirtualBox was acquired by the Sun Corporation in 2008 and Sun had put
> quite a  money to make VBox creation/administration GUI tools, including
> working metal->virtual converters.
>
> 4. Then Oracle bought Sun.
>
> Many small users expected that PUEL licensing -- as a part of Innotek
> acquisition
> deal -- will stay. It stood for the short period Oracle lawyers needed to
> null PUEL
> obligations Oracle inherited from Sun. Since then (v5.1 iirc) Virtualbox
> can
> be used for free only by pupils and hobbyists. (You're out of PUEL right at
> the first $1 earned on IT-related work, whether Virtualbox was involved or
> not).
>
>
> > The name 'Oracle' on that page does not discomfort me
>
> Me it disgusts a lot.
>
>
> P.S. This is really OT for the go-nuts list, but the Oracle's "alternative
> facts"
> that are spread in many media outlets need correction. I do not blame
> Michael Jones for falling a prey to that - he's within a legion.
>
> Hope this helps,
>
> --
> Wojciech S. Czarnecki
>  << ^oo^ >> OHIR-RIPE
>
> --
> 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/20190717114553.5c6793b7%40zuzia
> .
> 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/CAO6k0ute6_0_%2B5ikDS%2B3X1jdCO4K5mU_5qRo9yq%3DxtDFDH264Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: About the Google logo on the new Go website

[Michal Strba]

Okay, so just to explain why I started this topic and what exactly we are
talking about.

First of all, just to clear up any doubts, I have no problem with the logo.
Google 100% deserves to be there.

The thing that I'm talking about is this. Every once in a white, I come
across a discussion that starts like this:

*A:* I'm interested in Go, but I'm worried that Google [created it just for
its needs / has too much power over it / will throw it away just like many
other projects / doesn't care about the community / whatever, blah blah
Google].
*B:* Well, no! Go was started by people at Google, that's true, but it's
most and foremost a project led by great engineers and a great community
and is not a corporate product. Google doesn't care too much about Go and
Go would survive without Google.

The B guy is right!

However, many people seem to take it that since Google logo is on the page,
that actually, A guy is correct and Go is a corporate Google product, that
will perhaps vanish any day.

I wouldn't be worried about it if I didn't see the Reddit thread I linked,
which contained many irrational opinions of this kind. Here are a few:

> Well, in a way they're straight forward about it. They make it clear in
> this issue that Go is Google's language, the "community" around it is just
> allowed to send contributions that Google will include or not as they see
> fit.
>
This. They just proved that it is Google's language.
>
>> You needed proof?
>>
> Note that, by contrast, https://www.rust-lang.org/ doesn't have the
> Mozilla logo, even though Mozilla financially supports rust. Tells a lot
> about the differences in the governing models.
>
Google owns this language and dictates everything about it. It's only open
> source so we can hire better and get community contributions that we like
> for free
>
Pretty funny.. Why do people think go is not Google's language. The
> community gets to use it by accident. But that's ok Google was nice enough
> to open source it, so the community can fork whenever they feel like
>
I do understand that a Reddit discussion isn't particularly representative,
but these are some of the opinions circulating around the world! Seeing
these opinions amplified by the presence of the logo is the reasons I
started this thread. Not because I had anything against the logo personally.

ut 16. 7. 2019 o 22:30 JuciÊ Andrade  napísal(a):

> So a company spend millions on a tool that everybody may use freely and
> when they put a simple logo in the project page the sky falls down.
>
> Are you serious, people? I find hard to believe we are discussing that.
>
>
> --
> 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/add3a1b5-fb89-42ea-bad5-d99c02a3c5ed%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/CAO6k0utabMM%3DgOSB3PQ5k7wRbVbGsaKf7MVF-nkiF6OEBZYP4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] About the Google logo on the new Go website

[Michal Strba]

As you all know, the new, redesigned Go website has a Google logo in the
bottom right corner.

Someone opened an issue about this, worrying that with the logo, nobody
will see Go as a community project:
https://github.com/golang/go/issues/33021

The issue was promptly closed and locked by a Go team member, which I must
admit, is kind of an unfair move.

If you read this thread on r/programming, it seems like the worries are
quite justified:
https://www.reddit.com/r/programming/comments/ccidly/golang_issue_ticket_remove_the_google_logo/

I personally am fine with the logo.

What do you think? For example, Rust has no Mozilla logo on its page
despite being largely funded by it.

-- 
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/CAO6k0ustg3-Qe-Be4OKxXhDhj0A%2BLr%2BXWRE8Y5ZjVr_zz%2BeeVg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: errors/wrap.go looks like it could be made into a more general monad package?

[Michal Strba]

First of all, this is not at all what "monad" means. A monad is a way to
express threading of values between computations. A result of one
computation gets threaded as an input to the next one, and so on.

Second, what would be the use-case of this other than errors?

On Wed, Jul 3, 2019, 04:52 Gert  wrote:

> On Wednesday, July 3, 2019 at 3:03:20 AM UTC+2, Gert wrote:
>>
>> https://github.com/golang/go/blob/master/src/errors/wrap.go
>>
>> What if we replaced all error types in that file with a empty interface
>> or a general monad interface? Can we make it work for other types too and
>> introduce a new monad package instead a new error package only?
>>
>>
> ```
> package monad
>
> type Monad interface {
> Unwrap() Monad
> }
>
> func Unwrap(m Monad) Monad {
> if m != nil {
> return m.Unwrap()
> }
> return nil
> }
> ```
>
> ```
> package monad_test
>
> import (
> "monad"
> "testing"
> )
>
> type monadT struct{ s string }
>
> func (m monadT) Unwrap() monad.Monad { return nil }
>
> type wrappedT struct {
> s string
> m monad.Monad
> }
>
> func (w wrappedT) Unwrap() monad.Monad { return w.m }
>
> func TestUnwrap(t *testing.T) {
> m1 := monadT{"monad"}
> m2 := wrappedT{"monad wrap", m1}
>
> testCases := []struct {
> mmonad.Monad
> want monad.Monad
> }{
> {nil, nil},
> {wrappedT{"wrapped", nil}, nil},
> {m1, nil},
> {m2, m1},
> {wrappedT{"wrap 3", m2}, m2},
> }
> for _, tc := range testCases {
> if got := monad.Unwrap(tc.m); got != tc.want {
> t.Errorf("Unwrap(%v) = %v, want %v", tc.m, got, tc.want)
> }
> }
> }
> ```
>
> --
> 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/92fe566f-3f18-43a2-91a6-4db21a1ef4ee%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/CAO6k0uuDgv6G4tEU_LJBqwQhuRG842FEPjfPz2EG7NW39V1TjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] is there any type that cannot be sent on a channel?

[Michal Strba]

Not sure where you read that. Anything can be sent on a channel. Even
channels can be sent over channels. That's often used when one goroutine
needs to reply to a message from another goroutine.

ne 30. 6. 2019 o 18:31 Sathish VJ  napísal(a):

> I thought I read somewhere that functions cannot be sent on channels.  But
> I tried it out and it can be.  Play link:
> https://play.golang.org/p/OeLpQsNwnCn
>
> So, is there anything that cannot be sent on channels?
>
> --
> 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/608c41d5-a226-4d77-a8fc-c4563d69f5db%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/CAO6k0uuhmC6ryBnQp4kb3pG94Ly5o5r0ktVfCseeXK4_kZ91aA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: A proof-of-concept implementation of my generics proposal for Go

[Michal Strba]

I fixed the importing issues people were having with version of Go newer
than 1.10.

If you haven't tried the generics tool yet and you're interested, now it
should work for you!

It's a tool that takes a Go file which uses generics and translates it into
a regular Go code that you can run. It also does full type-checking of the
generic code.

On Fri, Jun 28, 2019, 05:14 Randall O'Reilly  wrote:

> I also like this proposal, and have a related proposal with a somewhat
> different syntax that is even simpler and is essentially identical to
> existing Go code, just with “Generic Native Types” (GNT).  Here’s a couple
> of side-by-side comparisons:
>
> ///
> // Min
>
> Michal’s:
>
> func Min(x, y type T ord) T {
> if x < y {
> return x
> }
> return y
> }
>
> GNT:
>
> func Min(x, y number) type(x) {
> …
> }
>
> ///
> // SyncMap
>
> Michal’s:
>
> type SyncMap(type K eq, type V) struct {
> mu sync.Mutex
> m  map[K]V
> }
>
> func (sm *SyncMap(type K eq, type V)) Store(key K, value V) {
> sm.mu.Lock()
> sm.m[key] = value
> sm.mu.Unlock()
> }
>
> GNT:
>
> type SyncMap struct interface {
> mu sync.RWMutex
> m  map   // a generic map
> }
>
> func (m *SyncMap) Store(k key(m.Map), v elem(m.Map)) {
> …
> }
>
> A struct interface is like an interface, specialized for struct -- any
> struct with the specified fields gets the generic methods, instantiated for
> the concrete type, e.g.,:
>
> // MySyncMap instantiates the SyncMap struct interface...
> type MySyncMap struct {
> mu sync.RWMutex
> m  map[string]string
> }
>
> Here’s a significantly improved version of the proposal originally posted
> a few weeks ago:
> https://gist.github.com/rcoreilly/bfbee2add03c76ada82810423d81e53d  This
> proposal also specifies a complete set of *fixed* “contracts” that are
> isomorphic to the existing native types, so it might appeal to people who
> prefer more explicit semantics for the generic args, compared to more
> generic generics.  Cheers,
>
> - Randy
>
> > On Jun 27, 2019, at 8:13 PM, Ben Hoyt  wrote:
> >
> > I really, really like this. I liked the original proposal, but using the
> "type" keyword seems very natural. And I like the 80/20 constraints thing
> with eq/ord/num. Good work -- I hope this gets turned into an official
> proposal and debated.
> >
> > -Ben
> >
> >
> > On Thursday, June 27, 2019 at 10:29:03 AM UTC-4, Michal Strba wrote:
> > Hey everybody!
> >
> > A few weeks ago, I posted about my proposal for generics in Go 2. You
> can find it here.
> >
> > Today, I finished a proof-of-concept implementation. It was a lot of fun
> and I learned a lot about the internals of Go.
> >
> > The implementation is a program that takes a Go file that uses generics
> and translates it to a regular Go file that you can run.
> >
> > Try it out here :)
> >
> > I'm looking forwad to all your feedback!
> >
> > Michal Štrba
> >
> > --
> > 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/199bad6c-ed62-44a6-960b-86503242537a%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/655EEB98-6928-48E9-84C4-24C259660E7D%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/CAO6k0uv%2BCpg%2BLBVb9SgM8-pF8D_DqqjjJcvMA3LKQmyjGu%2BfbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] A proof-of-concept implementation of my generics proposal for Go

[Michal Strba]

Hey everybody!

A few weeks ago, I posted about my proposal for generics in Go 2. You can 
find it here. 
<https://gist.github.com/faiface/e5f035f46e88e96231c670abf8cab63f>

Today, I finished a proof-of-concept implementation. It was a lot of fun 
and I learned a lot about the internals of Go.

The implementation is a program that takes a Go file that uses generics and 
translates it to a regular Go file that you can run.

Try it out here :) <https://github.com/faiface/generics>

I'm looking forwad to all your feedback!

Michal Štrba

-- 
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/0a042b10-acdc-48e1-80f6-cd05b4f687c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] bogus "missing return at end of function"

[Michal Strba]

Can you post a code (preferably a link to play.golang.org) that does this?

I can't reproduce it myself.

On Mon, Jun 10, 2019, 02:40 Marvin Renich  wrote:

> Is it already a known issue that a «for [true] { ... }» loop whose only
> exit path is through return statements inside the loop (i.e. no break
> statement) will produce the compiler error "missing return at end of
> function" if you don't put a meaningless "return ..." statement after
> the loop?
>
> If this issue is not already known, will someone who has a github
> account please file this issue for me?
>
> Thanks...Marvin
>
> --
> 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/20190610004002.ltcv36765lkn75xp%40basil.wdw
> .
> 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/CAO6k0uux2X6Y%2BDmvdP9FfL9kbirJD9vKTU%3D9Wz1sfYvM5ncFUw%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]

I really can’t promise to ever fully evaluate all generics proposals.

Perfectly understandable. I’ll show the benefits without you needing to
fully evaluate the proposal then :)

it’s still unusual in Go for a name that appears in a list to become in
scope for the rest of the list and for the following body.

Okay, so here is the main benefit of the scoping.

Let’s take this simple function that returns a static array with all
elements filled with some provided value.

Here’s how the signature would look in my proposal:

func Filled(gen n, x gen T) [n]T

And here’s how it would look if we had to list the generic arguments in a
separate list (feel free to supply gen with any other word):

func Filled(gen n, T)(x T) [n]T

Now, in this latter version, it’s not really clear how and where the
generic type gets inferred. Do I need to specify it manually? Under what
circumstances? When is the compiler able to infer it for me? Answers to
these questions are not clear.

On the other hand, in my proposal, the answers are very clear: unnamed
arguments get specified, everything else gets inferred.

func Filled(gen n, x gen T) [n]T//   ^^//
specified  inferred

Furthermore, there is never a choice between specifying and inferring a
generic type. The signature tells exactly which one the user must do.

One more minor benefit of this syntax is that it eliminates any extra
parentheses, keeping the clutter down and parsing easy.

I’ll respond to one more of your concerns.

There is also integer, signed integer, unsigned integer, comparable,
ordered, float, complex. One can even think of addable (includes string)
and indexable and sliceable.

Sure, we can imagine many ways of dividing types into groups. But just
because we can imagine that does not mean we need to.

I would argue that the “number contract” is far more useful than “addable”,
“indexable”, or anything else you can imagine.

The “number contract” would include all the number types (int*, uint*,
float*, complex*). Arithmetic and logic operations common to these types
would be available. This is a rich set of operations: +, -, *, /, <, >, and
so on. Also, all of these types allow using untyped integer constants as
their values.

Sure, you wouldn’t be able to put strings in Sum function with this
proposal, but do you really need to do that? I don’t think so.

št 6. 6. 2019 o 1:08 Ian Lance Taylor  napísal(a):

> On Wed, Jun 5, 2019 at 3:02 PM Michal Strba  wrote:
> >
> > Ian, have you had the time to evaluate the improvements to my proposal
> (the original one in this thread)? I'd love to hear if it has some more
> significat shortcomings and know what to think about. Or, if it has no
> perspective, I'd love to hear why.
> >
> > I know you're busy, so responding with "I haven't had the time yet" is
> completely understandable.
>
> I really can't promise to ever fully evaluate all generics proposals.
> There are simply too many of them.  All I can honestly do is throw out
> some quick comments, as I've done already.  If you want detailed
> feedback, I encourage you to seek it from other people.
>
> As I said in my reply to Randall earlier " relying on a general
> construct like "number" is problematic in Go.  There are many
> different ways to slice up Go's types.  "number" is just one of them.
> There is also integer, signed integer, unsigned integer, comparable,
> ordered, float, complex. One can even think of addable (includes
> string) and indexable and sliceable."
>
> I'm also still concerned about scoping.  You added some text, but it's
> still unusual in Go for a name that appears in a list to become in
> scope for the rest of the list and for the following body.
>
> 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/CAO6k0us4gdyXcq%2Bu4iXEs_xNhH2GV%2BT5Rtem6ZFXbnf_sRTE6A%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]

Ian, have you had the time to evaluate the improvements to my proposal (the
original one in this thread)? I'd love to hear if it has some more
significat shortcomings and know what to think about. Or, if it has no
perspective, I'd love to hear why.

I know you're busy, so responding with "I haven't had the time yet" is
completely understandable.

Thanks

On Wed, Jun 5, 2019, 22:18 Robert Engels  wrote:

>
>
>
>
>
>
> -Original Message-
> >From: Randall O'Reilly 
> >Sent: Jun 5, 2019 2:33 PM
> >To: Robert Engels 
> >Cc: Ian Lance Taylor , Michal Strba <
> faiface2...@gmail.com>, golang-nuts 
> >Subject: Re: [go-nuts] Go 2 generics counterproposal: giving up
> restricting types
> >
> >That is a good point of clarification about the specific limitation of
> this proposal: it specifically reifies the existing Go type system and does
> NOT enable the generic-ification of arbitrary novel types.  If you can
> build a specialized type out of generic versions of existing Go types, then
> you’re good, but if you need something entirely different, then this won’t
> do it.  The key question is whether having a really simple and tractable
> “native types” version of generics solves enough problems, while avoiding
> the challenges of going “fully generic”, to hit that “Go” minimalism sweet
> spot..
> >
> >- Randy
> >
> >> On Jun 5, 2019, at 1:17 PM, Robert Engels 
> wrote:
> >>
> >> That is not sufficient. You can't require the usage of the built-in
> map, as specialized maps may have a completely different structure (special
> hash tables when the keys are ints, or more commonly special CAS techniques
> for highly concurrent lock-free maps).
> >
> >--
> >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/735428D9-5630-4F56-88AD-0F8E9E8CC473%40gmail.com
> .
> >For more options, visit https://groups.google.com/d/optout.
>
> Even more common data structures like linked maps, tree maps/sets wouldn't
> be possible. I think custom data structures are the prime usage for
> generics - which is why I suggested that rather than doing generics, you
> could do something like this:
>
> map:=make(map[String]String,"ordered,concurrent")
>
> which would use different implementations as decided by the Go platform
> (with maybe some way of registering additional ones via C, etc.)
>
> It keeps the simplicity of Go, using the existing syntax, but allows
> custom data structures (although not written in Go - maybe?)
>
> I think data structures are 95% of the use case of generics, but that is
> just my opinion (although earlier Java based studies I referred to seemed
> to support the claim).
>

-- 
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/CAO6k0uu2%3DGriMy7gAYP2UMrApNg%2BN_WNR0_g5w0sRvvK7FvRqg%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]

> It at least
feels more like go, syntax-wise, than most, except for the num part,
which seems like an afterthought.

It is an afterthought. It wasn't in the original proposal and was invented
as a way to enable functions like Min, Max, and so on. But I realized that
it actually enables many cool things like various generic math structures,
vectors, matrices to work with arbitrary numeric types.

It is a special case, but if you try and make it general, you end up with
some sort of contracts, which may or may not be what you want, but is what
I've been trying to avoid here.

On Mon, Jun 3, 2019, 16:57 Martin Schnabel  wrote:

> I agree. That is a good point. I consider arrays an edge case. Although
> still important, it will probably not be all too common. So the extra
> verbosity should not be a problem.
>
> I am happy you generally agree and think these minor tweaks can make a
> big difference for the roll-out of the proposed feature, if accepted.
>
> I also think, that this is one of the better proposals. It at least
> feels more like go, syntax-wise, than most, except for the num part,
> which seems like an afterthought.
>
> Again thank you for your work exploring this!
>
> Best regards
>Marin
>
> On 03.06.19 15:49, Michal Strba wrote:
> > 'const' could be fine too. I guess this is mostly a matter of personal
> > preference.
> >
> > Regarding the array length syntax. It does require qualifying for two
> > reasons:
> >
> > 1. Unnamed arguments.
> > 2. Using 'gen' (or 'type', 'const') makes it easy to say "gen is not
> > allowed in the return types", which is an important rule. Without
> > qualification, this rule would be hard to express.
> >
> > On Mon, Jun 3, 2019, 15:26 Martin Schnabel  > <mailto:m...@mb0.org>> wrote:
> >
> > Hi Michal,
> >
> > I would argue that the 'const' keyword would by more correct. Because
> > the array length is and needs to be constant anyway. And it has
> > currently no valid meaning in a parameter list, just like with
> > the 'type' keyword. However i would argue that the array length, if
> > written as part of the array syntax, as in '[n]elem' does not need an
> > explicit keyword qualifier, because - again - it's unambiguous in the
> > parameter context. Would you agree?
> >
> > Best regards
> > Martin
> >
> > On 03.06.19 14:20, Michal Strba wrote:
> >  > Hi Martin.
> >  >
> >  > The proposal adds types as "values", but not really. You can only
> > accept
> >  > a type to a function, but you cannot return a type. That makes the
> >  > system far from a dependent type system, even with the support for
> >  > generic array lengths.
> >  >
> >  > Being able to return types from functions and use those functions
> in
> >  > types is what brings all the power (and complexity) of dependent
> > typing,
> >  > but what I proposed is just a simple system for explicit type
> > anotation
> >  > directly in the function signature.
> >  >
> >  > Regarding the 'gen' keyword, I chose it because I propose not only
> >  > generic types, but also generic array lengths. But you are right
> > that
> >  > using 'type' would probably be better. Do you think that using the
> >  > 'type' keyword also in the context of generic array lengths would
> > be fine?
> >  >
> >  > On Mon, Jun 3, 2019, 12:53 Martin Schnabel  > <mailto:m...@mb0.org>
> >  > <mailto:m...@mb0.org <mailto:m...@mb0.org>>> wrote:
> >  >
> >  > Hi,
> >  >
> >  > is my impression correct, that this proposal adds types as
> > values to
> >  > the
> >  > language? It's seems like it does the section 'Unnamed generic
> >  > arguments'. That by itself would go a long way and warrants
> some
> >  > discussion, I'd say.
> >  >
> >  > If so, then why use a new keyword 'gen'? Why not 'type'
> itself.
> >  > It would have some symmetry with how the func and struct
> > keywords are
> >  > used for closures and unnamed structs. The 'type' keyword has
> no
> >  > possible meaning in the parameter list currently.
> >  >
> >  > I use the 'gen' keyword a lot as identifier, mostly for
> > generators
> >  > and generated

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

[Michal Strba]

'const' could be fine too. I guess this is mostly a matter of personal
preference.

Regarding the array length syntax. It does require qualifying for two
reasons:

1. Unnamed arguments.
2. Using 'gen' (or 'type', 'const') makes it easy to say "gen is not
allowed in the return types", which is an important rule. Without
qualification, this rule would be hard to express.

On Mon, Jun 3, 2019, 15:26 Martin Schnabel  wrote:

> Hi Michal,
>
> I would argue that the 'const' keyword would by more correct. Because
> the array length is and needs to be constant anyway. And it has
> currently no valid meaning in a parameter list, just like with
> the 'type' keyword. However i would argue that the array length, if
> written as part of the array syntax, as in '[n]elem' does not need an
> explicit keyword qualifier, because - again - it's unambiguous in the
> parameter context. Would you agree?
>
> Best regards
>Martin
>
> On 03.06.19 14:20, Michal Strba wrote:
> > Hi Martin.
> >
> > The proposal adds types as "values", but not really. You can only accept
> > a type to a function, but you cannot return a type. That makes the
> > system far from a dependent type system, even with the support for
> > generic array lengths.
> >
> > Being able to return types from functions and use those functions in
> > types is what brings all the power (and complexity) of dependent typing,
> > but what I proposed is just a simple system for explicit type anotation
> > directly in the function signature.
> >
> > Regarding the 'gen' keyword, I chose it because I propose not only
> > generic types, but also generic array lengths. But you are right that
> > using 'type' would probably be better. Do you think that using the
> > 'type' keyword also in the context of generic array lengths would be
> fine?
> >
> > On Mon, Jun 3, 2019, 12:53 Martin Schnabel  > <mailto:m...@mb0.org>> wrote:
> >
> > Hi,
> >
> > is my impression correct, that this proposal adds types as values to
> > the
> > language? It's seems like it does the section 'Unnamed generic
> > arguments'. That by itself would go a long way and warrants some
> > discussion, I'd say.
> >
> > If so, then why use a new keyword 'gen'? Why not 'type' itself.
> > It would have some symmetry with how the func and struct keywords are
> > used for closures and unnamed structs. The 'type' keyword has no
> > possible meaning in the parameter list currently.
> >
> > I use the 'gen' keyword a lot as identifier, mostly for generators
> > and generated code. While nobody can claim to use 'type'. This would
> > make converting code so much easier, if this proposal is accepted.
> >
> > Just a though. Please tell me whether this would be possible.
> >
> > Thanks for your work, it's much appreciated.
> > Martin
> >
> >
> > On 30.05.19 14:08, Michal Strba wrote:
> >  > Hi Gophers! :)
> >  >
> >  > I've been thinking about generics in Go 2 ever since the original
> >  > contracts proposal and few days ago, ideas finally clicked. One
> > of the
> >  > main things about this proposal is that it deliberately omits the
> >  > ability to restrict the set of types a function can work with.
> > This is a
> >  > limitation, but I hope to convince you that we can still do a vast
> >  > majority of the things we were missing, when we were missing
> > generics.
> >  >
> >  > I'd love to share my proposal with you and engage in a good faith
> >  > conversation.
> >  >
> >  > Link to the proposal.
> >  > <https://gist.github.com/faiface/e5f035f46e88e96231c670abf8cab63f
> >
> >  >
> >  > Here's what the proposal covers:
> >  >
> >  > 1. Syntax of a new gen keyword.
> >  > 2. Generic functions.
> >  > 3. Unnamed generic arguments (a.k.a. a way to gve a type to the
> > built-in
> >  > newfunction).
> >  > 4. Semantics of generic values (ability to use them as map keys,
> > ...).
> >  > 5. Generic array lengths.
> >  > 6. Reflection and interface{}.
> >  > 7. Generic types (with two examples: Listand Matrix).
> >  > 8. Generic methods and their limitations due to reflection.
> >  > 9. Generic interfaces.
> >  > 10. List of things this proposal can't do.
> >  >
> >  >

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

[Michal Strba]

Hi Martin.

The proposal adds types as "values", but not really. You can only accept a
type to a function, but you cannot return a type. That makes the system far
from a dependent type system, even with the support for generic array
lengths.

Being able to return types from functions and use those functions in types
is what brings all the power (and complexity) of dependent typing, but what
I proposed is just a simple system for explicit type anotation directly in
the function signature.

Regarding the 'gen' keyword, I chose it because I propose not only generic
types, but also generic array lengths. But you are right that using 'type'
would probably be better. Do you think that using the 'type' keyword also
in the context of generic array lengths would be fine?

On Mon, Jun 3, 2019, 12:53 Martin Schnabel  wrote:

> Hi,
>
> is my impression correct, that this proposal adds types as values to the
> language? It's seems like it does the section 'Unnamed generic
> arguments'. That by itself would go a long way and warrants some
> discussion, I'd say.
>
> If so, then why use a new keyword 'gen'? Why not 'type' itself.
> It would have some symmetry with how the func and struct keywords are
> used for closures and unnamed structs. The 'type' keyword has no
> possible meaning in the parameter list currently.
>
> I use the 'gen' keyword a lot as identifier, mostly for generators
> and generated code. While nobody can claim to use 'type'. This would
> make converting code so much easier, if this proposal is accepted.
>
> Just a though. Please tell me whether this would be possible.
>
> Thanks for your work, it's much appreciated.
>Martin
>
>
> On 30.05.19 14:08, Michal Strba wrote:
> > Hi Gophers! :)
> >
> > I've been thinking about generics in Go 2 ever since the original
> > contracts proposal and few days ago, ideas finally clicked. One of the
> > main things about this proposal is that it deliberately omits the
> > ability to restrict the set of types a function can work with. This is a
> > limitation, but I hope to convince you that we can still do a vast
> > majority of the things we were missing, when we were missing generics.
> >
> > I'd love to share my proposal with you and engage in a good faith
> > conversation.
> >
> > Link to the proposal.
> > <https://gist.github.com/faiface/e5f035f46e88e96231c670abf8cab63f>
> >
> > Here's what the proposal covers:
> >
> > 1. Syntax of a new gen keyword.
> > 2. Generic functions.
> > 3. Unnamed generic arguments (a.k.a. a way to gve a type to the built-in
> > newfunction).
> > 4. Semantics of generic values (ability to use them as map keys, ...).
> > 5. Generic array lengths.
> > 6. Reflection and interface{}.
> > 7. Generic types (with two examples: Listand Matrix).
> > 8. Generic methods and their limitations due to reflection.
> > 9. Generic interfaces.
> > 10. List of things this proposal can't do.
> >
> > Thanks,
> > faiface
> >
> > --
> > 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
> > <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/golang-nuts/6f5f0785-93f7-475a-991c-fc919c5e6730%40googlegroups.com
> > <
> https://groups.google.com/d/msgid/golang-nuts/6f5f0785-93f7-475a-991c-fc919c5e6730%40googlegroups.com?utm_medium=email_source=footer
> >.
> > 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/739d147e-162d-14fc-a13a-9e7962f074e2%40mb0.org
> .
> 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/CAO6k0ut8W8STeA6_AadA9FbL7HxkVimKMfMT3bTBtxDyP1N5_w%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] 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.

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

[Michal Strba]

Ian and David, thanks for the response! I personally don't consider MIn and
Max to be so important, however, I understand if you do. I've added a new
little part to the proposal that describes one possible way for them to be
supported:

Currently, the type-checker has to distinguish between three kinds of
> generic parameters:
>
> 1. Any type.
> 2. Any type with `==`.
> 3. Integer constant.
>
> This list could be extended to include support for _any numeric type_
> (with operators like `+`, `-`, ...). This would make it possible to make
> functions like `Min`, `Max`, and so on.
>

I've also added a better description of the scope of the identifiers
declared with the gen keyword as Ian pointed out:

The identifier after `gen` is then a generic type identifier visible in the
> whole rest of the function (signature and body).



št 30. 5. 2019 o 21:44 David Riley  napísal(a):

> On May 30, 2019, at 2:25 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.
>
> I agree strongly with this metric. My principal reason for wanting
> generics is precisely so I can avoid writing the kind of repetitive code
> that I currently need to write to perform the exact same simple operations
> on similar datatypes.  Min and Max are perfect examples of that, Map and
> Filter are slightly more complex ones.
>
> If I can't write Min and Max for generic data types, I'm not using it.
> YMMV.
>
>
> - Dave

-- 
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/CAO6k0uv4RTP5kDsgNwB-KoWy8z1ErpMpVFieX%2BincRvHvHXmOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Michal Strba]

I agree with that. What exactly do you consider cryptic, though, about
my proposal? I thought the syntax was very clean. Furthermore,
regarding relating this to C++, I quote:

> Just to make it clear, you aren't allowed to use operators like +, -, <, call 
> methods, or access struct fields of a generic value

I'm just not sure how your sentiment relates to the proposal.

št 30. 5. 2019 o 19:41  napísal(a):
>
> Sorry again for the power failure...let me try one last time
>
> one of the annoying things you have to deal with as a team member is being 
> assigned an "update" of code written by someone who no longer works for the 
> team.
> What makes this annoying is possibility of running into code sections that 
> contain "crytic" statements that require lots of effort to understand.
>  After looking at the link you provided, based on my history dealing with 
> unnecessary and avoidable 'cryptic C++,
>  my input  is:  Generics are a great idea EXCEPT when they allow use of 
> cryptic syntax
>
> On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, Michal Strba wrote:
>>
>> Hi Gophers! :)
>>
>> I've been thinking about generics in Go 2 ever since the original contracts 
>> proposal and few days ago, ideas finally clicked. One of the main things 
>> about this proposal is that it deliberately omits the ability to restrict 
>> the set of types a function can work with. This is a limitation, but I hope 
>> to convince you that we can still do a vast majority of the things we were 
>> missing, when we were missing generics.
>>
>> I'd love to share my proposal with you and engage in a good faith 
>> conversation.
>>
>> Link to the proposal.
>>
>> Here's what the proposal covers:
>>
>> 1. Syntax of a new gen keyword.
>> 2. Generic functions.
>> 3. Unnamed generic arguments (a.k.a. a way to gve a type to the built-in new 
>> function).
>> 4. Semantics of generic values (ability to use them as map keys, ...).
>> 5. Generic array lengths.
>> 6. Reflection and interface{}.
>> 7. Generic types (with two examples: List and Matrix).
>> 8. Generic methods and their limitations due to reflection.
>> 9. Generic interfaces.
>> 10. List of things this proposal can't do.
>>
>> Thanks,
>> faiface
>
> --
> 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/4e266f34-32d8-4b3d-8f45-55da5651ed9e%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/CAO6k0usA%3D6EdH6mpTPqYnpnEBWNu8GST%2Bam-G2rQEZNPGUPC7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Michal Strba]

> Generics are useful except when their syntax becomes cryptic 

I agree, are you referring to anything specific?

Dňa štvrtok, 30. mája 2019 19:29:09 UTC+2 L Godioleskky napísal(-a):
>
>
>
> On Thursday, May 30, 2019 at 1:24:55 PM UTC-4, L Godioleskky wrote:
>>
>> one of the annoying things you have to deal with as a team member is 
>> being assigned an "update" of code written by someone who no longer works 
>> for the team. What makes this annoying is possibility of running into code 
>> sections that contain "crytic" statements that require lots of effort to 
>> understand. After looking at the link you provided my input, based on 
>> dealing with cryptic C++  is: Go should not allow cryptic syntax.
>>
> Generics are useful except when their syntax becomes cryptic 
>  
>
>>   w
>>
>> On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, Michal Strba wrote:
>>>
>>> Hi Gophers! :)
>>>
>>> I've been thinking about generics in Go 2 ever since the original 
>>> contracts proposal and few days ago, ideas finally clicked. One of the main 
>>> things about this proposal is that it deliberately omits the ability to 
>>> restrict the set of types a function can work with. This is a limitation, 
>>> but I hope to convince you that we can still do a vast majority of the 
>>> things we were missing, when we were missing generics. 
>>>
>>> I'd love to share my proposal with you and engage in a good faith 
>>> conversation.
>>>
>>> Link to the proposal. 
>>> <https://gist.github.com/faiface/e5f035f46e88e96231c670abf8cab63f>
>>>
>>> Here's what the proposal covers:
>>>
>>> 1. Syntax of a new gen keyword.
>>> 2. Generic functions.
>>> 3. Unnamed generic arguments (a.k.a. a way to gve a type to the built-in 
>>> new function).
>>> 4. Semantics of generic values (ability to use them as map keys, ...).
>>> 5. Generic array lengths.
>>> 6. Reflection and interface{}.
>>> 7. Generic types (with two examples: List and Matrix).
>>> 8. Generic methods and their limitations due to reflection.
>>> 9. Generic interfaces.
>>> 10. List of things this proposal can't do.
>>>
>>> Thanks,
>>> faiface
>>>
>>

-- 
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/042a2594-1a00-43e9-8866-86c362d9298b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Michal Strba]

Hi Gophers! :)

I've been thinking about generics in Go 2 ever since the original contracts 
proposal and few days ago, ideas finally clicked. One of the main things 
about this proposal is that it deliberately omits the ability to restrict 
the set of types a function can work with. This is a limitation, but I hope 
to convince you that we can still do a vast majority of the things we were 
missing, when we were missing generics. 

I'd love to share my proposal with you and engage in a good faith 
conversation.

Link to the proposal. 


Here's what the proposal covers:

1. Syntax of a new gen keyword.
2. Generic functions.
3. Unnamed generic arguments (a.k.a. a way to gve a type to the built-in new 
function).
4. Semantics of generic values (ability to use them as map keys, ...).
5. Generic array lengths.
6. Reflection and interface{}.
7. Generic types (with two examples: List and Matrix).
8. Generic methods and their limitations due to reflection.
9. Generic interfaces.
10. List of things this proposal can't do.

Thanks,
faiface

-- 
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/6f5f0785-93f7-475a-991c-fc919c5e6730%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics

[michal]

Google has it's own tool that is publicly available as part of gvisor 
project [1] I think it's as good or better than the provided options.
I copied that to enable installation using plain go get (without bazel) [2].
We used that to de-interface github.com/fatih/set so you may see a real 
usage example [3].

[1] https://github.com/google/gvisor/tree/master/tools/go_generics
[2] https://github.com/mmatczuk/go_generics
[3] https://github.com/scylladb/go-set

$ go get github.com/mmatczuk/go_generics/cmd/...
$ go_generics -h
Usage: go_generics [options]
  -ast
prints the AST
  -c A=B
reassign constant A to value B when A=B is passed in. Multiple such 
mappings are allowed.
  -i file
input file
  -import name=path
specifies the import libraries to use when types are not local. 
name=path specifies that 'name', used in types as name.type, refers to the 
package living in 'path'.
  -o file
output file
  -p name
output package name (default "main")
  -prefix prefix
prefix to add to each global symbol
  -suffix suffix
suffix to add to each global symbol
  -t A=B
rename type A to B when A=B is passed in. Multiple such mappings 
are allowed.

On Tuesday, December 11, 2018 at 11:25:57 PM UTC+1, Tharaneedharan 
Vilwanathan wrote:
>
> Thank you for the details!
>
> Regards
> dharani
>
>
> On Tue, Dec 11, 2018 at 2:13 AM > wrote:
>
>> Here are some code generators that let you define template parameters:
>>
>> https://github.com/cheekybits/genny
>> https://github.com/taylorchu/generic
>> https://github.com/joeshaw/gengen
>> https://github.com/clipperhouse/gen
>>
>> Making use of Go templates:
>>
>> https://github.com/ncw/gotemplate
>> https://github.com/droundy/gotgo
>>
>> Am Dienstag, 11. Dezember 2018 04:00:57 UTC+1 schrieb Tharaneedharan 
>> Vilwanathan:
>>>
>>> Hi All,
>>>
>>> I have a quick question.
>>>
>>> What is the best choice for writing generic code till Go officially 
>>> supports generics? Just looking for some guidance.
>>>
>>> Regards
>>> dharani
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Starlight - run python inside Go to extend your applications - easily

[michal]

On Tuesday, December 11, 2018 at 3:35:37 AM UTC+1, Jason E. Aten wrote:
>
> For full, actual python inside Go, one could combine:
>
> (a) https://github.com/iodide-project/pyodide  has the python scientific 
> stack compiled to wasm (python + numpy + scipy + numplotlib)
>
> and
>
> (b) either https://github.com/go-interpreter/wagon or 
> https://github.com/perlin-network/life 
> :
>  
> each provide a wasm byte-code interpreter as a Go library.
>

Thanks for sharing that, that's some fresh thinking here.
 

>
>
> On Monday, December 10, 2018 at 2:39:09 AM UTC-6, mic...@scylladb.com 
> wrote:
>>
>>
>>
>> On Friday, December 7, 2018 at 9:05:02 PM UTC+1, Nate Finch wrote:
>>>
>>> I’d like to announce starlight - 
>>> https://github.com/starlight-go/starlight.
>>>
>>>
>>> Starlight wraps google’s Go implementation of the starlark python 
>>> dialect  (most notably found in 
>>> the Bazel build tool). Starlight makes it super easy for users to extend 
>>> your application by writing simple python scripts that interact seamlessly 
>>> with your current Go code… with no boilerplate on your part.
>>>
>>
>> Do you think it is suitable for porting python applications?
>> Usually you go through cgo like this 
>> https://www.datadoghq.com/blog/engineering/cgo-and-python/ it could be 
>> an interesting alternative. 
>>  
>>
>>>
>>> *Parser by google*
>>>
>>> The parser and runner are maintained by google’s bazel team, which write 
>>> starlark-go. Starlight is a wrapper on top of that, which makes it so much 
>>> easier to use starlark-go. The problem with the starlark-go API is that it 
>>> is more built to be a used as configuration, so it assumes you want to get 
>>> information out of starlark and into Go. It’s actually pretty difficult to 
>>> get Go information into a starlark script…. unless you use starlight.
>>>
>>> *Easy two-way interaction*
>>>
>>>
>>> Starlight has adapters that use reflection to automatically make any Go 
>>> value usable in a starlark script. Passing an *http.Request into a 
>>> starlark script? Sure, you can do name = r.URL.Query()["name"][0] in 
>>> the python without any work on your part.
>>>
>>> Starlight is built to *just work* the way you hope it’ll work. You can 
>>> access any Go methods or fields, basic types get converted back and forth 
>>> seamlessly… and even though it uses reflection, it’s not as slow as you’d 
>>> think. A basic benchmark wrapping a couple values and running a starlark 
>>> script to work with them runs in a tiny fraction of a millisecond.
>>>
>>> The great thing is that the changes made by the python code are 
>>> reflected in your go objects, just as if it had been written in Go. So, set 
>>> a field on a pointer to a struct? Your go code will see the change, no 
>>> additional work needed.
>>>
>>> *100% Safe*
>>>
>>>
>>> The great thing about starlark and starlight is that the scripts are 
>>> 100% safe to run. By default they have no access to other parts of your 
>>> project or system - they can’t write to disk or connect to the internet. 
>>> The only access they have to the outside is what you give them. Because of 
>>> this, it’s safe to run untrusted scripts (as long as you’re not giving them 
>>> dangerous functions to run, like os.RemoveAll). But at the same time, 
>>> if you’re only running trusted scripts, you can give them whatever you want 
>>> (http.Get? Sure, why not?)
>>>
>>> *Caching*
>>>
>>>
>>> In a production environment, you probably want to only read a script 
>>> once and parse it once. You can do that with starlight’s Cache. This 
>>> cache takes a list of directories to look in for scripts, which it will 
>>> read and parse on-demand, and then store the parsed object in memory for 
>>> later use. It also uses a cache for any load() calls the scripts use to 
>>> load scripts they depend on.
>>>
>>> *Work Ongoing*
>>>
>>>
>>> Starlight is still a work in progress, so don’t expect the API to be 
>>> perfectly stable quite yet. But it’s getting pretty close, and there 
>>> shouldn’t be any earth shattering changes, but definitely pin your imports. 
>>> Right now it’s more about finding corner cases where the starlight wrappers 
>>> don’t work quite like you’d expect, and supporting the last few things that 
>>> aren’t implemented yet (like channels).
>>>
>>>
>>> *Example*
>>>
>>>
>>> Here's a simple example of how easy it is to extend the behavior of your 
>>> application with a python script.  Just pass starlight whatever go values 
>>> you want your python script to act on, and any changes the python code 
>>> makes get reflected in your go code.  
>>>
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "log"
>>> "time"
>>>
>>> "github.com/starlight-go/starlight"
>>> )
>>>
>>> // Starlight makes it easy to get values in and out of your starlark 
>>> scripts.

[go-nuts] Re: Starlight - run python inside Go to extend your applications - easily

[michal]

On Friday, December 7, 2018 at 9:05:02 PM UTC+1, Nate Finch wrote:
>
> I’d like to announce starlight - https://github.com/starlight-go/starlight
> .
>
>
> Starlight wraps google’s Go implementation of the starlark python dialect 
>  (most notably found in the Bazel 
> build tool). Starlight makes it super easy for users to extend your 
> application by writing simple python scripts that interact seamlessly with 
> your current Go code… with no boilerplate on your part.
>

Do you think it is suitable for porting python applications?
Usually you go through cgo like 
this https://www.datadoghq.com/blog/engineering/cgo-and-python/ it could be 
an interesting alternative. 
 

>
> *Parser by google*
>
> The parser and runner are maintained by google’s bazel team, which write 
> starlark-go. Starlight is a wrapper on top of that, which makes it so much 
> easier to use starlark-go. The problem with the starlark-go API is that it 
> is more built to be a used as configuration, so it assumes you want to get 
> information out of starlark and into Go. It’s actually pretty difficult to 
> get Go information into a starlark script…. unless you use starlight.
>
> *Easy two-way interaction*
>
>
> Starlight has adapters that use reflection to automatically make any Go 
> value usable in a starlark script. Passing an *http.Request into a 
> starlark script? Sure, you can do name = r.URL.Query()["name"][0] in the 
> python without any work on your part.
>
> Starlight is built to *just work* the way you hope it’ll work. You can 
> access any Go methods or fields, basic types get converted back and forth 
> seamlessly… and even though it uses reflection, it’s not as slow as you’d 
> think. A basic benchmark wrapping a couple values and running a starlark 
> script to work with them runs in a tiny fraction of a millisecond.
>
> The great thing is that the changes made by the python code are reflected 
> in your go objects, just as if it had been written in Go. So, set a field 
> on a pointer to a struct? Your go code will see the change, no additional 
> work needed.
>
> *100% Safe*
>
>
> The great thing about starlark and starlight is that the scripts are 100% 
> safe to run. By default they have no access to other parts of your project 
> or system - they can’t write to disk or connect to the internet. The only 
> access they have to the outside is what you give them. Because of this, 
> it’s safe to run untrusted scripts (as long as you’re not giving them 
> dangerous functions to run, like os.RemoveAll). But at the same time, if 
> you’re only running trusted scripts, you can give them whatever you want (
> http.Get? Sure, why not?)
>
> *Caching*
>
>
> In a production environment, you probably want to only read a script once 
> and parse it once. You can do that with starlight’s Cache. This cache 
> takes a list of directories to look in for scripts, which it will read and 
> parse on-demand, and then store the parsed object in memory for later use. 
> It also uses a cache for any load() calls the scripts use to load scripts 
> they depend on.
>
> *Work Ongoing*
>
>
> Starlight is still a work in progress, so don’t expect the API to be 
> perfectly stable quite yet. But it’s getting pretty close, and there 
> shouldn’t be any earth shattering changes, but definitely pin your imports. 
> Right now it’s more about finding corner cases where the starlight wrappers 
> don’t work quite like you’d expect, and supporting the last few things that 
> aren’t implemented yet (like channels).
>
>
> *Example*
>
>
> Here's a simple example of how easy it is to extend the behavior of your 
> application with a python script.  Just pass starlight whatever go values 
> you want your python script to act on, and any changes the python code 
> makes get reflected in your go code.  
>
>
> package main
>
> import (
> "fmt"
> "log"
> "time"
>
> "github.com/starlight-go/starlight"
> )
>
> // Starlight makes it easy to get values in and out of your starlark 
> scripts.
> // Just pass in pointers to values that you want changed, or callback 
> functions
> // that propagate data.
>
> // In theory, starlight also returns all global variables set by the 
> script, but
> // in real programs, you need well-defined outputs for your calling code 
> to act on.
> // If I write a script that creates a variable called nate_is_awesome = 
> 1337 ... your
> // go code probably isn't going to care that the variable exists.
>
> // The best way to do it is to write a "results" struct that you pass in, 
> just
> // as you would for any other function.
>
> type Page struct {
> Name string
> Date time.Time
> Contents string
> IsDraft bool
> }
>
> const code = `
> def run():
> if "nate" in page.Name:
>  # capitalize words
>  page.Name = page.Name.title()
> page.Name += " " + page.Date.Format("2006/01/02")
> page.IsDraft = False
> run()
> `
>
> func main() {
> p := {
> Name: 

[go-nuts] Re: HTTP/2 Adventure in the Go World

[michal]

That's cool, I'm not sure if the locks on Conn object [1] are needed, could 
it just rely on locking in http2?

[1] https://github.com/posener/h2conn/blob/master/conn.go#L18

On Sunday, August 12, 2018 at 4:40:03 PM UTC+2, Eyal wrote:
>
> Hi,
> You are welcome to read a blog post I wrote about a short experience with 
> HTTP/2 and Go.
>
> https://posener.github.io/http2/
>
> Cheers,
> Eyal
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] [ANN]: go_generics code template engine for Go that Google was hiding from you :)

[michal]

TL;DR you can go-get go_generics - no Bazel needed

go_generics [1] is a tool that was first observed few months back with the 
release of gVisor. It allows for generating code from template while still 
working with standard Go code. It's a great improvement over working with 
Go templates but nothing like C++ templates.

We used it at Scylla to create go-set [2] a replacement for fatih/set [3] 
package. This approach allows for working with plain types instead of 
interface{} thus eliminating "escape to heap" problem and improving 
performance x10 in some cases.

The reason to fork it was a messy build process with Bazel. To streamline 
things for go-set [2] we fixed that so you can now just go-get the tool. 
The tool is universal and can be a good fit in almost any project.

Enjoy!

[1] https://github.com/mmatczuk/go_generics

[2] https://github.com/scylladb/go-set

[3] https://github.com/fatih/set

Michal

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] [ANN]: go_generics code template engine for Go that Google was hiding from you :)

[michal]

TL;DR you can go-get go_generics - no Bazel needed


go_generics [1] is a tool that was first observed few months back with the 
release of gVisor. It allows for generating code from template while still 
working with standard Go code. It's a great improvement over working with 
Go templates but nothing like C++ templates.


We used it at Scylla to create go-set [2] a replacement for fatih/set [3] 
package. This approach allows for working with plain types instead of 
interface{} thus eliminating "escape to heap" problem and improving 
performance x10 in some cases.


The reason to fork it was a messy build process with Bazel. To streamline 
things for go-set [2] we fixed that so you can now just go-get the tool. 
The tool is universal and can be a good fit in almost any project.


Enjoy!


[1] https://github.com/mmatczuk/go_generics

[2] https://github.com/scylladb/go-set

[3] https://github.com/fatih/set


Michal

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [ANN] go-set type-safe sets for Go

[michal]

Update:

We have made generating sets for your own types really easy now:

* go_generate tool was forked and you can just go-get it, see 
https://github.com/mmatczuk/go_generics
* all the generation procedure was wrapped in a bash script

In addition to that the original set implementation from 
github.com/fatih/set package was improved, most notably Copy, Union and 
Intersect are smarter in terms of memory management.

On Monday, August 6, 2018 at 7:26:23 PM UTC+2, hen...@scylladb.com wrote:
>
> Go-set is a type-safe, zero-allocation set implementation for Go.
>
> https://github.com/scylladb/go-set
>
> At Scylla we are long time users of https://github.com/fatih/set 
> 
>  
> and after it’s discontinuation we wanted to still use it. We therefore 
> created an enhanced clone with a typesafe API and high performance.
>
> We like generics a lot so we used the Google tool “go_generics” from the 
> gVisor [1]  code base to generate the concrete implementations. Most of the 
> simple language builtin types are supported.
>
>
> If you enjoy go-set come work with us, we are hiring Go Developers. Learn 
> more at https://www.scylladb.com/company/careers/
>
>
> [1] https://github.com/google/gvisor/tree/master/tools/go_generics
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] [ANN] sqlx for cassandra gocqlx v1.0.0 released

[michal]

GoCQLX is a general purpose extensions to golang's Cassandra driver gocql.

With gocqlx you can bind query parameters from maps and structs, 
use named query parameters (:identifier) and scan query results into 
structs and slices. 
It comes with a fluent and flexible CQL query builder and a database 
migrations module.

https://github.com/scylladb/gocqlx

--

If you enjoy hacking database drivers and building tools come [join 
us](https://www.scylladb.com/company/careers/).

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Multi line go generate vs Bash script

[michal]

I have a use case where I use multi line go generate, similar to 
https://github.com/containous/traefik/blob/master/generate.go

//go:generate rm -vf autogen/gen.go
//go:generate mkdir -p static
//go:generate go-bindata -pkg autogen -o autogen/gen.go ./static/... 
./templates/... 

Would you recommend refactoring this to a single go generate and a bash 
script?

--
Michał Matczuk

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Golang should have a center packages index hosting like npm, rust crates

[Michal Bohuslávek]

It's not much of a penalisation IMO. It doesn't have to be a large message 
in red saying: "The author of this package doesn't use semantic versioning. 
Be careful!". I mean the list of versions can only appear if there are some 
versions. That way it wouldn't penalise a), although I can't come up with a 
good reason not to tag versions apart from b).

When it comes to b), there could be some rule for that case. Such authors 
could for example put their stable API in a branch called "stable" or 
something like that.

Dne čtvrtek 27. října 2016 1:39:47 UTC+1 Axel Wagner napsal(a):
>
> So, the idea is to penalize people who a) have a different opinion about 
> the usefulness of versioning or b) keep their APIs stable and don't see a 
> need to version something that never changes?
>
> Needless to say, I consider that a bad idea (given, that I have strongly 
> differing opinions about the usefulness of versioning). Why can't the idea 
> not succeed based on it's own merit (or lack thereof)?
>
> But whatever. Set minds won't be swayed by arguments, I guess.
>
> I'll also point out (again) that this thread, originally, was about a 
> central repository. Not about versioning.
>
> On Wed, Oct 26, 2016 at 10:53 PM, Edward Muller  > wrote:
>
>> Yes, use that proposal's format.
>>
>> Re: godoc. Great idea. if no one else is interested in doing the work 
>> I'll be happy to take a look into it. I've been looking for an excuse to 
>> work with gddo
>>
>> On Wed, Oct 26, 2016 at 1:42 PM Dave Cheney > > wrote:
>>
>>> Indeed. If only there was some standard we could use
>>>
>>>
>>> https://github.com/golang/proposal/blob/master/design/12302-release-proposal.md#tag-format
>>>
>>> On Thu, Oct 27, 2016 at 6:08 AM, Nate Finch >> > wrote:
>>> > Listing versions on godoc is an awesome idea.  Peer pressure goes a 
>>> long way
>>> > toward changing individual minds and eventually a community.  
>>> Something as
>>> > simple as sorting projects with tagged versions higher and displaying 
>>> them
>>> > prominently on the project's godoc page (with the ability to look at 
>>> godoc
>>> > for each version) would go a long way toward encouraging people to tag 
>>> their
>>> > releases.  I know it would get me off my butt to tag my projects.
>>> >
>>> > On Wednesday, October 26, 2016 at 11:37:54 AM UTC-4, 
>>> mbohu...@gmail.com
>>> > wrote:
>>> >>
>>> >> I was just wondering whether a simple list of available versions at 
>>> the
>>> >> top of a package's godoc.org page wouldn't somehow force package 
>>> authors to
>>> >> start tagging. There could be some kind of message if there are no 
>>> available
>>> >> versions.
>>> >> There would obviously have to be some benefit for those who tag, or 
>>> some
>>> >> restriction for those who don't, in order to change the current 
>>> situation.
>>>
>>> --
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.