[go-nuts] Re: Implement generic type interface

[Denis Cheremisov]

GoLand' support for generics is in alpha stage today, false negatives are 
pretty common and this is your case.

понедельник, 24 января 2022 г. в 20:02:09 UTC+3, ka...@swit.io: 

> Before the question, I'm sorry I'm not good at English
>
> when go 1.18 beta released, i try to test generic type 
> Most of the code worked, but something went wrong when implementing the 
> generic interface.
>
> This is my code >
> type Repository[T any] interface {
> Save(T) T
> }
>
> type repo[T any] struct {
> }
>
> func NewRepository[T any]() Repository[T] {
> return [T]{}
> }
>
> func (r repo[T]) Save(entity T) T {
> return entity
> }
>
> This code looks fine and works normally when executed.
> But, ide throw compile exception. Why?
>
> [image: 스크린샷 2022-01-24 오후 7.12.19.png]
>
> * Again, build and run is normal *
>

-- 
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/6d6e9cd7-6529-49dc-9209-9e64b2663aa2n%40googlegroups.com.

Re: [go-nuts] Re: Generating go code using go templates

[Denis Cheremisov]

Trees although better in general than template still have one critical 
disadvantage: it is hard to control a code they produces.I tried approaches 
with templates, line by line and trees. Line by line is generally the best 
of them.
понедельник, 20 сентября 2021 г. в 23:15:22 UTC+3, chet...@gmail.com: 

> Yes. Generating large portions of code via templates is going to be hard. 
> Especially reusing and maintaining it.
> There is an excellent library called jennifer - 
> https://github.com/dave/jennifer that lets you generate Go code by 
> building the syntax tree. The examples make it super simple to get started. 
> You might want to check it out.
>
> On Monday, September 20, 2021 at 12:29:51 PM UTC-7 va...@selfip.ru wrote:
>
>> I'm writing a code generator from protobuf via templates and i can say - 
>> debugging it is very hard. When you have big files you can't check syntax 
>> easily, don't know how it looks and if you have errors in the template it 
>> is really hard to fix them.
>> So the protoc-gen-go case is preferable.
>>
>> вс, 19 сент. 2021 г. в 04:33, Denis Cheremisov :
>>
>>> Templates is the worst approach to code generation IMO. Take a look how 
>>> they do this in protoc-gen-go: 
>>>
>>> https://github.com/protocolbuffers/protobuf-go/blob/b92717ecb630d4a4824b372bf98c729d87311a4d/cmd/protoc-gen-go/internal_gengo/main.go#L83
>>>
>>> I am using very similar approach, albeit I prefer format lines, it looks 
>>> like:
>>> [image: Screenshot from 2021-09-19 04-22-26.png]
>>>
>>> Templates may be OK only in trivial cases. Once you need something less 
>>> trivial it is getting harder and harder to reason how the final code will 
>>> look like with them
>>> and you will end up with bunch of hard to manage templates. Unlike it, 
>>> line-by-line code generation keep staying close to the final code.
>>> вторник, 7 сентября 2021 г. в 22:53:51 UTC+3, amitl...@gmail.com: 
>>>
>>>>
>>>> Hi gophers,
>>>> I wrote https://github.com/fluhus/goat for generating go code in my 
>>>> projects. I hope it can help you too. It's a minimal tool that takes a 
>>>> text/template <https://pkg.go.dev/text/template> template as input, 
>>>> runs it on the given parameters and gofmt's the output. You can also use 
>>>> it 
>>>> on non-go-source.
>>>> Feedback is welcome.
>>>>
>>>> Amit
>>>>
>>> -- 
>>> 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.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/406179d9-c8f5-497d-8832-ea04ff9d03b3n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/406179d9-c8f5-497d-8832-ea04ff9d03b3n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> -- 
>> Vasiliy Tolstov,
>> e-mail: v.to...@selfip.ru
>>
>

-- 
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/a34732e5-e6c5-4a91-9c55-2aa57d927b01n%40googlegroups.com.

[go-nuts] Re: Generating go code using go templates

[Denis Cheremisov]

Templates is the worst approach to code generation IMO. Take a look how 
they do this in protoc-gen-go: 
https://github.com/protocolbuffers/protobuf-go/blob/b92717ecb630d4a4824b372bf98c729d87311a4d/cmd/protoc-gen-go/internal_gengo/main.go#L83

I am using very similar approach, albeit I prefer format lines, it looks 
like:
[image: Screenshot from 2021-09-19 04-22-26.png]

Templates may be OK only in trivial cases. Once you need something less 
trivial it is getting harder and harder to reason how the final code will 
look like with them
and you will end up with bunch of hard to manage templates. Unlike it, 
line-by-line code generation keep staying close to the final code.
вторник, 7 сентября 2021 г. в 22:53:51 UTC+3, amitl...@gmail.com: 

>
> Hi gophers,
> I wrote https://github.com/fluhus/goat for generating go code in my 
> projects. I hope it can help you too. It's a minimal tool that takes a 
> text/template  template as input, runs 
> it on the given parameters and gofmt's the output. You can also use it on 
> non-go-source.
> Feedback is welcome.
>
> Amit
>

-- 
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/406179d9-c8f5-497d-8832-ea04ff9d03b3n%40googlegroups.com.

[go-nuts] Re: [Macos/Apple M1] some fork/exec … operation not permitted error

[Denis Cheremisov]

Found what causes this. An extended Apple attribute apple.com.quarantine. 
Set it off, then need to set off some other utilities and now it is done.

вторник, 8 декабря 2020 г. в 18:07:17 UTC+3, Denis Cheremisov: 

> Hi! I installed Go via sources
>
> $ go version
> go version devel +9c91cab0da Tue Dec 8 01:46:45 2020 + darwin/arm64
>
> got better performance than I had with my aging Core i5 4670k, etc, this 
> was expectable, no surprises here.
>
> But, there's an issue. When I call `go get`, `go install`, etc via 
> `exec.Command` I get this error:
>
> self check: update pedro-miguel: run go get 
> gitlab.stageoffice.ru/UCS-TOOLS/pedro-miguel: fork/exec 
> /usr/local/go/bin/go: operation not permitted
>
> What may cause this? Launching other utilities works fine:
>
> package main
>
> import (
> "os"
> "os/exec"
> )
>
> func main() {
> cmd := exec.Command("echo", "hello!")
> cmd.Stdout = os.Stdout
> if err := cmd.Run(); err != nil {
> panic(err)
> }
> }
>
> PS pedro-miguel named after a cascade of locks in Panama channel.
>

-- 
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/d9945b23-4178-4062-9283-fe0115dcbabbn%40googlegroups.com.

[go-nuts] [Macos/Apple M1] some fork/exec … operation not permitted error

[Denis Cheremisov]

Hi! I installed Go via sources

$ go version
go version devel +9c91cab0da Tue Dec 8 01:46:45 2020 + darwin/arm64

got better performance than I had with my aging Core i5 4670k, etc, this 
was expectable, no surprises here.

But, there's an issue. When I call `go get`, `go install`, etc via 
`exec.Command` I get this error:

self check: update pedro-miguel: run go get 
gitlab.stageoffice.ru/UCS-TOOLS/pedro-miguel: fork/exec 
/usr/local/go/bin/go: operation not permitted

What may cause this? Launching other utilities works fine:

package main

import (
"os"
"os/exec"
)

func main() {
cmd := exec.Command("echo", "hello!")
cmd.Stdout = os.Stdout
if err := cmd.Run(); err != nil {
panic(err)
}
}

PS pedro-miguel named after a cascade of locks in Panama channel.

-- 
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/21d6e61d-0f01-4e4a-b44d-60a3b4878603n%40googlegroups.com.

[go-nuts] Re: Any recommendation for structured logging library in Golang?

[Denis Cheremisov]

Zerolog does the trick, need a bit of setup though for what you want

среда, 18 ноября 2020 г. в 07:21:48 UTC+3, ChrisLu: 

> I am considering moving from glog to structured logging. I tried logrus, 
> go-kit, uber/zap, but could not find one good fit. In short, this is the 
> desired format:
>
> [info][timestamp] [filename:line_number] message k1=v1 k2=v2 ...
>
> It shows the correct file name(need to pop out a few call stacks) and line 
> number in a customizable format, not as key-value pair for each line which 
> is just too verbose to have the extra "time=" "file=".
>
> Please let me know the one you actually use.
>
>
> Thanks!
> Chris
> -
> https://github.com/chrislusf/seaweedfs
>

-- 
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/5cff0a88-bcb5-4f5b-bc8f-8ca3e838ff19n%40googlegroups.com.

Re: [go-nuts] Licence details of github.com/golang/sync

[Denis Cheremisov]

Well, as usual I wrote something in the way, not the real thing.

The case is:

- At my company we are using errgroup from that sync repo in one project,
  sync/errgroup in fact mostly.
- It proved to be error prone with its context shadowing on 
errgroup.WithContext
  so we took the original and adds context in the group itself via eg.Ctx() 
+ 
  a couple of additional functionality.

Yesterday our attorney wrote us "we can't use sync because of this patents
note" as it works like a virus, and can't use our modification too for the 
same
reason. It turned out the stdlib is under the same note too, so we will have
fun times :) 

четверг, 29 октября 2020 г. в 20:09:59 UTC+3, ohir: 

> Dnia 2020-10-29, o godz. 06:52:17
> Denis Cheremisov  napisał(a):
>
> > Hi!
> > At my job we found these additional patents 
> > limitatations https://github.com/golang/sync/blob/master/PATENTS
> > They makes us impossible to use errgroup (which is, to say, turned to 
> have 
> > pretty poor choice of WithContext signature, so our one is different), 
> so 
> > we have our custom implementation of it with additonal functionality 
> > (errors collector, concurrency limitation), but it is derived from the 
> > original implementation.
>
> This list is not a proper venue to gather 'common-sense' legal advice, as 
> such
> advice will likely be at odds with your real legal standing regarding your 
> software
> under each next jurisdiction.
>
> To be clear and a bit assured about your real situation you should hire a 
> good attorneys
> in each country of interest or hire a top-tier international law agency 
> then make sure to
> be very frank with them about what you did, what you do, and what you plan 
> to do with
> your implementation.
>
> Hope this helps,
>
> -- 
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>
> P.S. My "Common-sense" advice is this: as whole Go ecosystem is under this 
> grant,
> if it is stands against your planned deeds, you certainly should abandon 
> Go right now
> and switch to Java or Swift ASAP. There you'll be covered by Oracle's or 
> Apple's
> voluminouos license agreements that will make the "very close to" problem
> disappear, as it will be clearly forbidden ;).
>

-- 
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/1db53b86-32fd-4a43-9bf4-d39fde9ed96dn%40googlegroups.com.

[go-nuts] Licence details of github.com/golang/sync

[Denis Cheremisov]

Hi!
At my job we found these additional patents 
limitatations https://github.com/golang/sync/blob/master/PATENTS
They makes us impossible to use errgroup (which is, to say, turned to have 
pretty poor choice of WithContext signature, so our one is different), so 
we have our custom implementation of it with additonal functionality 
(errors collector, concurrency limitation), but it is derived from the 
original implementation.

I guess the repository should be called "github.com/google/sync" after 
that. Anyway, our product's proprietary licence makes it impossible to use 
our derived implementation. Is there a way to overcome this somehow? The 
problem is my own implementation would be really close to this and thus 
prone to a sue.

-- 
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/b50fccd3-a026-4227-82ad-2e41e82cbea6n%40googlegroups.com.

Re: [go-nuts] Re: protobuf avoid namespace conflict

[Denis Cheremisov]

It is because you import protoc-gen-go generated entities with exactly the 
same package name and their own name. This is not allowed with protobuf, 
you can only have a single .. You can either use 
different names for error packages or use a 3rd repository with generated 
code.

среда, 30 сентября 2020 г. в 18:14:04 UTC+3, va...@selfip.ru: 

> server https://github.com/unistack-org/micro-server-grpc
> client https://github.com/unistack-org/micro-client-grpc
> code used both repos 
> https://github.com/unistack-org/micro-tests/tree/master/server/grpc
>
> ср, 30 сент. 2020 г. в 16:41, Joop Kiefte :
>
>> This seems to be because the protocol buffer packages rely on shared 
>> state, kinda similar to the registration of database drivers in 
>> database/sql I would say (correct me if I'm wrong). I don't know how you 
>> import them, but you probably need a way to strictly separate the two in 
>> your program (example code would help to give more specific advice...).
>>
>>   *Joop Kiefte* - Chat @ Spike 
>>  [image: 
>> pgfpn]
>>
>> On September 30, 2020 at 13:26 GMT, Vasiliy Tolstov  
>> wrote:
>>
>>
>> So nobody knows how to deal with this? And if some projects have proto
>> files with the same name - protobuf always complain about it?
>>
>> вт, 29 сент. 2020 г. в 10:50, Vasiliy Tolstov :
>> >
>> > Hi! I have two packages server and client. All belongs to different
>> > repos. In this packages i have internal/errors dir with errors.proto
>> > file
>> > Both of them contains go_package option and package unique
>> >
>> > option go_package = "xxx.org/server/internal/errors";
>> > package server.errors;
>> >
>> > option go_package = "xxx.org/client/internal/errors";
>> > package client.errors;
>> >
>> > why program that used client and server in the same time have such 
>> message
>> >
>> > 2020/09/29 10:50:18 WARNING: proto: file "errors.proto" is already 
>> registered
>> > previously from: ""xxx.org/server/internal/errors"
>> > currently from: ""xxx.org/client/internal/errors"
>> > A future release will panic on registration conflicts. See:
>> > 
>> https://developers.google.com/protocol-buffers/docs/reference/go/faq#namespace-conflict
>> >
>> > --
>> > Vasiliy Tolstov,
>> > e-mail: v.to...@selfip.ru
>>
>>
>>
>> -- 
>> Vasiliy Tolstov,
>> e-mail: v.to...@selfip.ru
>>
>> -- 
>> 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+unsub...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CACaajQvaGd8j2MD75EkRvH6zxD89gyKLunxXL6Q5%3DN9VkKWWhQ%40mail.gmail.com.
>>
>>
>>
>
> -- 
> Vasiliy Tolstov,
> e-mail: v.to...@selfip.ru
>

-- 
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/5df715d7-ba19-46e5-ad1d-1c5dd5c896ddn%40googlegroups.com.

Re: [go-nuts] how to use replace directives in go.mod in dev but not prod

[Denis Cheremisov]

CI probably is the anwser, made a utility based on golang.org/x/mod which 
parses go.mod and checks if replaces are there and exit with error state if 
they are.

вторник, 22 сентября 2020 г. в 11:21:55 UTC+3, Paul Jolly: 

> 26640 is an open issue describing the same problem you're describing. 
> Unfortunately because it remains open there is not yet a solution.
>
>
> On Tue, 22 Sep 2020, 07:36 Alex Mills,  wrote:
>
>> i dont understand, is there a solution or just a proposal?
>>
>> On Mon, Sep 21, 2020, 23:03 Paul Jolly  wrote:
>>
>>> I just replied. I think that https://github.com/golang/go/issues/26640
>>> covers this.
>>>
>>> On Tue, 22 Sep 2020 at 06:52, Alex Mills  wrote:
>>> >
>>> > I put this question on the golang issue tracker on github:
>>> > https://github.com/golang/go/issues/41546
>>> >
>>> > I am sure it's been answered before but hard to search for..anyone 
>>> know what the right approach is? I like how node.js / NPM solve it using 
>>> symlinks personally.
>>> >
>>> > --
>>> > 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.
>>> > To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/92794ec1-ee89-4c98-820e-750b1db079ffn%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/8a09fad1-005d-44f7-a0bd-7092edf2d643n%40googlegroups.com.

[go-nuts] Re: [ generics] Moving forward with the generics design draft

[Denis Cheremisov]

Oops, I meant "all interfaces can be used as a constraint yet there are 
interfaces that can be used as a value's type"

-- 
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/c0d414a5-070a-4e2b-8ebe-9f375d719ec6n%40googlegroups.com.

[go-nuts] Re: [ generics] Moving forward with the generics design draft

[Denis Cheremisov]

> But I don't think that using type list constraint as sum types is good 
idea.
> Type constraints should be known in compile-time, but the sum type 
variant should be known in run-time.

It looks like you misunderstand it a bit. Indeed

type Constraint interface {
type Type₁, Type₂, …, Typeₙ
}

was introduced as a meta-construct. Some people, including me, were not 
particularly happy about it, as it
cannot be used as a value type and assymetry appears: all interfaces can be 
used as a constraint yet there
are interfaces that can't. An obvious inconsistency. So, they (the Go team) 
addressed this with an idea to
utilize such kind of interfaces for runtime values as a sum type.

I really wish they make it into Go together with generics too. Some parts 
of my code would finally be
straightforward.

пятница, 4 сентября 2020 г. в 21:45:48 UTC+3, tdakkota: 

> I'd like to see sum types in Go2 and there are many reasons: 
> - It can make using oneOf/anyOf in protobuf or swagger mush easier.
> - It can make ast.Node type-safe. 
> - With sum-types compiler known maximum size of variant, so it can be 
> allocated on stack, not on heap.
>
> But I don't think that using type list constraint as sum types is good 
> idea.
> Type constraints should be known in compile-time, but the sum type variant 
> should be known in run-time.
> пятница, 21 августа 2020 г. в 03:28:23 UTC+3, Ian Lance Taylor: 
>
>> After many discussions and reading many comments, we plan to move 
>> forward with some changes and clarifications to the generics design 
>> draft. 
>>
>> 1. 
>>
>> We’re going to settle on square brackets for the generics syntax. 
>> We’re going to drop the “type” keyword before type parameters, as 
>> using square brackets is sufficient to distinguish the type parameter 
>> list from the ordinary parameter list. To avoid the ambiguity with 
>> array declarations, we will require that all type parameters provide a 
>> constraint. This has the advantage of giving type parameter lists the 
>> exact same syntax as ordinary parameter lists (other than using square 
>> brackets). To simplify the common case of a type parameter that has 
>> no constraints, we will introduce a new predeclared identifier “any” 
>> as an alias for “interface{}”. 
>>
>> The result is declarations that look like this: 
>>
>> type Vector[T any] []T 
>> func Print[T any](s []T) { … } 
>> func Index[T comparable](s []T, e T) { … } 
>>
>> We feel that the cost of the new predeclared identifier “any” is 
>> outweighed by the simplification achieved by making all parameter 
>>
> lists syntactically the same: as each regular parameter always has a 
>> type, each type parameter always has a constraint (its meta-type). 
>>
>> Changing “[type T]” to “[T any]” seems about equally readable and 
>> saves one character. We’ll be able to streamline a lot of existing 
>> code in the standard library and elsewhere by replacing “interface{}” 
>> with “any”. 
>>
>> 2. 
>>
>> We’re going to simplify the rule for type list satisfaction. The type 
>> argument will satisfy the constraint if the type argument is identical 
>> to any type in the type list, or if the underlying type of the type 
>> argument is identical to any type in the type list. What we are 
>> removing here is any use of the underlying types of the types in the 
>> type list. This tweaked rule means that the type list can decide 
>> whether to accept an exact defined type, other than a predeclared 
>> type, or whether to accept any type with a matching underlying type. 
>>
>> This is a subtle change that we don’t expect to affect any existing 
>> experimental code. 
>>
>> We think that this definition might work if we permit interface types 
>> with type lists to be used outside of type constraints. Such 
>> interfaces would effectively act like sum types. That is not part of 
>> this design draft, but it’s an obvious thing to consider for the 
>> future. 
>>
>> Note that a type list can mention type parameters (that is, other type 
>> parameters in the same type parameter list). These will be checked by 
>> first replacing the type parameter(s) with the corresponding type 
>> argument(s), and then using the rule described above. 
>>
>> 3. 
>>
>> We’re going to clarify that when considering the operations permitted 
>> for a value whose type is a type parameter, we will ignore the methods 
>> of any types in the type list. The general rule is that the generic 
>> function can use any operation permitted by every type in the type 
>> list. However, this will only apply to operators and predeclared 
>> functions (such as "len" and "cap"). It won’t apply to methods, for 
>> the case where the type list includes a list of types that all define 
>> some method. Any methods must be listed separately in the interface 
>> type, not inherited from the type list. 
>>
>> This rule seems generally clear, and avoids some complex reasoning 
>> involving type lists that include structs with embedded type 
>> 

Re: [go-nuts] rin: return if nil syntactic sugar

[Denis Cheremisov]

> I am using flutter and so Dart for the frontend right now, and I have 
come to a

Error context has a little value in the end user apps, I noticed this too 
at the example of just CLI utilities. It is totally different when it comes 
to modern network systems, because there're far more places of errors 
there. Imagine you have requested an item and this leads to fetching data 
from several sources and you got an error at one. Imagine you did not 
decorate it and got some basic network error. It will be nearly useless as 
it is. Decorated one will be useful:

return errors.Wrap(err, "request something from service.method")

And you are asking engineers what is wrong with that service, or dig into 
yourself. Problem solved.

Sure, it is artificial example, but the pricnicple is one: there are lots 
of places where you can get at error in distributed systems. Context is 
extremely useful.

понедельник, 31 августа 2020 г. в 12:06:16 UTC+3, m8il...@gmail.com: 

> On 2020-08-31 03:34, Ian Lance Taylor wrote:
> >> Idk if this has been proposed or discussed before.
> >>
> >> Given the last error handling abbreviation proposal is rejected. How 
> about some simple syntactic sugar like this:
> >>
> >> rin Something()
> >>
> >> Which is just a sugar for:
> >>
> >> if err := Something(); err != nil {
> >> return err
> >> }
> >>
> >> To make it worth the new keyword make it so that:
> >>
> >> rin v := Something()
> >>
> >> equals to:
> >>
> >> v, err := Something()
> >> if err != nil {
> >> return err
> >> }
> > This is similar to the check/handle design draft, without the handle.
> > You may want to take a look at https://golang.org/issue/40432.
> > Thanks.
>
> I am using flutter and so Dart for the frontend right now, and I have come 
> to a
> conclusion that is related but perhaps beyond magical. It is my opinion 
> that
> having additional syntax simply for syntactic sugar reasons offers little
> benefit but pointless cognitive load when reading code. I now remove 
> syntactic
> sugar in Dart like => and ... in my codebases. As the full syntax does the 
> same
> thing but offers greater functionality, I see negatives with negligible 
> benefit
> in any case.
>
> Especially when there is the potential for code readers to switch from 
> backend
> to frontend and not necessarily being masters in both languages.
>

-- 
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/70a1bb39-cb66-4447-86a4-11a67c576d75n%40googlegroups.com.

Re: [go-nuts] [ generics] Moving forward with the generics design draft

[Denis Cheremisov]

> possibility of using angle brackets

Please stop 

   - call these operator signs “brackets”
   - pretending they are good in a role of brackets — they are not
   - spreading this nonsense from C syntax family of languages to saner 
   once — yes, you heard it right. C is known for its chaotic development and 
   lack of careful planning.
   - thinking yet another strange workaround is a good thing


среда, 26 августа 2020 г. в 00:38:00 UTC+3, Kaveh Shahbazian: 

> I am excited about sum-types as much as generics themselves. Also, it's 
> nice that any is a keyword restricted to be used inside the type parameter 
> declaration as a type constraint.
>
> Very nice!
>
> ---
>
> P.S.
> Of-course now the proposal seems to go with brackets. Nevertheless, I 
> wrote this comment 
>  on 
> the possibility of using angle brackets for the type parameter declaration. 
> Maybe that way there are more symbols in the language. But they will be 
> less overloaded with (completely) different semantics - assuming it's a 
> practical approach.
>
> On Tuesday, August 25, 2020 at 12:35:33 AM UTC+2 Ian Lance Taylor wrote:
>
>> On Thu, Aug 20, 2020 at 9:54 PM Ian Lance Taylor  
>> wrote: 
>> > 
>> > Our intent here is that "any" will be available for all code. Yes, we 
>> > wouldn't do it if it weren't for its use as a type constraint. But if 
>> > we are going to do it for type constraints, there seems to be little 
>> > benefit to restricting it to only work as a type constraint. 
>> > 
>> > This is not, of course, a new idea, even in the absence of generics. 
>> > For example, https://golang.org/issue/33232. (My comment there was 
>> > that we would use interface{} less if we had generics, but of course 
>> > when we require type constraints then we actually wind up using it 
>> > somewhat more.) 
>>
>> I've seen objections that a language change for generics should not 
>> implicitly pull in a change to non-generic code. That seems fair. It 
>> may be the right thing to do, but it should be justified separately. 
>> So we're going to start with "any" only being accepted as a type 
>> constraint, and we can discuss making the name available for all uses 
>> separately, probably on issue 33232. Clearly adding "any" as a name 
>> accepted in type constraints is a step toward defining "any" for all 
>> code, but doing so isn't a requirement for generics. 
>>
>> 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/41f63ef1-ac34-4d43-88fc-4ce75bcc262dn%40googlegroups.com.

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

[Denis Cheremisov]

I probably didn't read what you have wrote in the first message carefuly 
enough. Does it mean something like that will work

type SomeTypes interface {
type int, float32, float64
}

func Min[T SomeTypes](x, y T) T {
switch T {
case int:
if x < y {
return x
}
return y
case float32:
return math.Min(float64(x), float64(y))
case float64:
return math.Min(x, y)
}
}

Would something like below work as well?

type Compare[T any] interface {
Compare(x, y T) int
}

type CompareConstraints[T any] {
type int, int8, …, float64, string, Compare[T]
}

func Min[T CompareConstraints]Min(x, y T) bool {
switch T {
case int:
…
…
case Compare[T]:
return x.Compare(y) < 0
}
}

понедельник, 24 августа 2020 г. в 06:40:52 UTC+3, Ian Lance Taylor: 

> On Sun, Aug 23, 2020 at 3:00 PM Juliusz Chroboczek  wrote:
> >
> > > We’re going to permit type switches on type parameters that have type
> > > lists, without the “.(type)” syntax. The “(.type)” syntax exists to
> > > clarify code like “switch v := x.(type)”.
> >
> > Could you please give an example of the proposed syntax?
>
> func F[T constraints.Integer]() {
> switch T {
> case int:
> case int8:
> }
> }
>
> 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/4e9391f0-f688-4189-8822-39fc8e217b70n%40googlegroups.com.

Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

[Denis Cheremisov]

You may use something like this

*value2 := 
*(*uint64)(unsafe.Pointer(uintptr(unsafe.Pointer()) + 8))*
*if value2 == 0 {*
*return true*
*}*

on AMD64, should work also for any 64 bit architecture (at least I believe 
so). Remember though this is hacky and may stop working once.


воскресенье, 23 августа 2020 г. в 22:58:51 UTC+3, Aviv Eyal: 

> I was trying to show that the current behavior is confusing and that 
> fmt.Print() needing to resort to panic-and-recover is kinda code smell, but 
> I sorts-of convinced myself that the current behavior is right, or at least 
> consistent.
>
> In my code, I got bit because I sometimes use v *Type to denote "I may or 
> may not have a value here" (where Type is a value-type). 
> This is probably a bad practice on my behalf, because I break the Liskov 
> substitution principle: there is a value of `*Type` that is not a valid 
> value of `Type`, and I let this value slip by.
>
> In this case, `v Type` implements Stringer (i.e. valid callee for 
> `v.String()`, but `v *Type`, in the strictest sense, does not.
> The only reason we can write:
>
> func (Type) String() string {...}
> v *Type = {...}
> _ = v.String()
>
> and have it compile, is syntactic sugar: `v` gets implicitly 
> de-referenced, and there's an implicit assumption that it's not nil.
> And there's a matching syntactic sugar for converting `Type` to a `*Type`.
>
> So, In the code:
>
> func (Type) String() string {...}
>
> v *Type = nil
> r interface{} = v
> _, ok = r.(Stringer)
>
> What I really want to ask is "Can I, at runtime, call r.String()?", 
> whereas the question Go answers is "Is any of `r`, `*r`, or `` defines 
> .String()?" - which matches the static semantics of `r.String()`.
>
> So, while I should probably not use *Type as a replacement for 
> Optional, I think it might make sense to have some operator that can 
> determine, at run-time, if a call `r.String()` is valid (including a 
> nil-check).
>
>
> -- Aviv
>
> On Saturday, April 11, 2020 at 4:48:28 PM UTC+3 ren...@ix.netcom.com 
> wrote:
>
>> I agree with the OP. The usefulness of nil interfaces is pretty limited. 
>> Show me a useful case that cant easily be implemented with non-nil 
>> interfaces. 
>>
>> I would argue that allowing nil interfaces causes more subtle latent bugs 
>> and makes it harder to reason about the correctness of code when reviewing 
>> it. 
>>
>> It just feels wrong. I realize I’m probably in the minority here but the 
>> OP is not alone. 
>>
>> On Apr 11, 2020, at 8:20 AM, 'Axel Wagner' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>> On Fri, Apr 10, 2020 at 7:17 PM  wrote:
>>
>>> I realize I'm reviving an age-old discussion here and apologize for 
>>> bringing up the undead. I happend to run into this when my application 
>>> panicked when some interfaces where initialized with nil mock objects 
>>> instead of being left uninitialized as in production mode.
>>>
>>
>> Let's imagine a world in which `foo == nil` also is true if `foo` is an 
>> interface-value containing a nil-pointer. Let's say in this world, someone 
>> sends a message to golang-nuts. They wrote a mock for the same code. And 
>> since it's just a mock, they just returned static value from its methods 
>> and didn't need to care if the pointer was nil or not. They are confused, 
>> because the passed in this mock, but the code just assumed the field was 
>> uninitialized and never called into their mock. What would you tell them? 
>> Why is their confusion less valid?
>>
>> This would be an example where a nil implementing fooer is never caught:
>>>
>>> type fooer interface {
>>>  foo()
>>> }
>>>
>>> type other struct{}
>>>
>>> func (o *other) foo() {} // implement fooer
>>>
>>> func main() {
>>>  var f fooer
>>>
>>>  var p *other // nil
>>>  f = p // it is a fooer so I can assign it
>>>
>>>  if f == nil {
>>> // will not get here
>>>  }
>>> }
>>>
>>>
>>> My confusion comes from the point that the nil interface is apparently 
>>> not "a nil-pointer with the correct method set" while *other is even if nil.
>>>
>>
>> In the code you posted, even a nil *other is a perfectly fine 
>> implementation of fooer. You can call `(*other)(nil).foo()` without any 
>> problems.
>> So, as you illustrated, calling methods on a nil-pointer can be totally 
>> fine. A nil-interface, OTOH, doesn't have any methods to call, as it 
>> doesn't contain a dynamic value. If you write `(*other)(nil).foo()`, it is 
>> completely clear what code gets called - even if that code *might* panic. 
>> If you write `fooer(nil).foo()`, what code should be called in your opinion?
>>
>> I think it's easy to see that a nil-interface and a nil-pointer stored in 
>> an interface are very different things. Even from first principles, without 
>> deep knowledge of the language. And if they are obviously different, I 
>> don't understand why you'd find it confusing that they are not the same in 
>> this 

Re: [go-nuts] [ generics] Moving forward with the generics design draft

[Denis Cheremisov]

BTW, I am really glad your proposal is accepted, now the whole thing feels 
polished and IMO it is time to start building an implementation.

пятница, 21 августа 2020 г. в 20:02:17 UTC+3, Carla Pfaff: 

> On Friday, 21 August 2020 at 16:46:22 UTC+2 bbse...@gmail.com wrote:
>
>> All constraints except "any" specify a constraint for the type. A 
>> Stringer constraint will ensure that the type has String() string 
>> method. "any" is a lack of constraint. 
>
>
> The empty interface / any is a constraint that ensures that the type has 
> at least 0 methods and all of these 0 methods must match the 0 methods of 
> the interface. An empty purse is still a purse, an empty constraint is 
> still a constraint.
>  
>
>> My problem is the attractiveness of "any" as a return type. 
>>
>
> I don't see why anybody would find it attractive as a return type. People 
> don't use the empty interface because they like it so much, but because Go 
> doesn't have parametric polymorphism / "generics" yet. There are many 
> programming languages that have a named top type and it is rarely abused. 
> Programmers want to write type safe code if they can.
>

-- 
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/137a5799-2bb7-402c-a972-e7da0789c890n%40googlegroups.com.

Re: [go-nuts] Re: Why we don't have simple throws error statement

[Denis Cheremisov]

Even worse: no idea where the error actually happened.
вторник, 18 августа 2020 г. в 13:33:54 UTC+3, semi...@gmail.com: 

> Another idea, if we use blank identifier for errors then throws statement 
> catch these with caller function name.
>
> func printSum(a, b, c string) error { 
>  throws func(caller string, err error) {
>  fmt.Println("caller:", caller, err)
>  return err
>  }()
>
>  x, _ := strconv.Atoi(a)
>  y, _ := strconv.Atoi(b) 
>  z, err := strconv.Atoi(c)
>  if err != nil {
>  return err
>  }
>
>  fmt.Println("result:", x + y + z)
>
>  return nil
> }
>
> How is sound?
>
> Semih.
> On Sunday, 2 August 2020 at 11:44:43 UTC+3 Denis Cheremisov wrote:
>
>> There are two major issues with Go error handling:
>>
>>
>>1. It is not strict enough, i.e. the compiler cannot ensure error 
>>check
>>2. It is not consistent enough.
>>
>> In the first you can easily ignore an error and the compiler will let you 
>> go further. In the second, you can both
>>
>> *if err := doSomething(); err != nil {*
>> *}*
>>
>> and
>>
>> *v, err := returnSomething()*
>> *if err != nil {*
>> *}*
>>
>> *or err* would do this better for sure
>>
>> *doSomething() or err {*
>> *}*
>>
>> and
>>
>> *v := returnSomething() or err {*
>> *}*
>>
>> воскресенье, 2 августа 2020 г. в 03:55:59 UTC+3, skinne...@gmail.com: 
>>
>>> I do not consider error handling an issue but then again I tend to 
>>> either use the Doit() err{} or MustDoit(){} panic and then use  DI 
>>> (dependency injection implemented by interface) for error-handling so that 
>>> I can get an email when we get a new error. So then it would be 
>>> MustDoit(errorHandler("ConIo")){} 
>>>
>>> Actually I suppose it is an issue, I do not do error handling in Go, but 
>>> my preprocessor converts it to Go. Go error handling can do anything, the 
>>> implementation may not be clear and that may be the real problem. We can 
>>> change it by improving the language or by training programmers on 
>>> recognizing useful abstractions, may need both.
>>>
>>>
>>> On Saturday, August 1, 2020 at 1:31:54 PM UTC-5 Ian Lance Taylor wrote:
>>>
>>>> On Sat, Aug 1, 2020 at 10:59 AM  wrote: 
>>>> > 
>>>> > Has anyone ever tallied the number of different forum threads related 
>>>> to changing Go error handling ? 
>>>> > The current method is obviously a vexing issue to many Go users, and 
>>>> > It seems silly that this issue has never been resolved by the Go team 
>>>> beyond maintaining the status quo... despite, IMHO, several good 
>>>> alternatives that have been suggested on this very forum. 
>>>>
>>>> There have been many alternatives suggested, but none of them have 
>>>> been clearly better. 
>>>>
>>>> I recently wrote a brief overview at https://golang.org/issue/40432. 
>>>>
>>>> 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/0dd99e65-7823-4f6b-a08d-95aa6f0ebaccn%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[Denis Cheremisov]

> Have the authors considered the implications of requiring the `type` 
keyword to use a generic type, not just at declaration time? Would this 
open up more syntax possibilities, such as `var x T`? This might 
be easier to read at the expense of five more characters of typing. It also 
could unify declaration and usage syntax even more than the proposal.

> This might be easier to read

Square brackets are easier to read. They are larger and catchier to eyes 
than lesser and greater signs used as brackets. And type-less syntax with 
mandatory constraint is even easier and feels like a great match with the 
rest of the language.


четверг, 6 августа 2020 г. в 22:25:19 UTC+3, Red Daly: 

> Have the authors considered the implications of requiring the `type` 
> keyword to use a generic type, not just at declaration time? Would this 
> open up more syntax possibilities, such as `var x T`? This might 
> be easier to read at the expense of five more characters of typing. It also 
> could unify declaration and usage syntax even more than the proposal.
>
> (Personally, I will accept any syntax. It's not realistic to expect this 
> for go2, but I would prefer if go3 ditched the C-style syntax altogether in 
> favor of a simpler, lisp-style syntax. Such a syntax would make it easier 
> to introduce language features like this one. Macros and metaprogramming 
> would also be much more straightforward for users to add useful 
> abstractions to the language.)
> On Thursday, August 6, 2020 at 7:15:08 AM UTC-7 Mike Schinkel wrote:
>
>> Hi Russ,
>>
>> In general, I think the proposal is a really good one.  I like that you 
>> abandoned contracts as interfaces were just too similar, and personally I 
>> like the choice of square brackets.
>>
>> There are a few aspects I do not like — 1.) no zero value and 2.) lack of 
>> covariance and contravariance — but perhaps those can be addressed in the 
>> future?
>>
>> All in all, I think the team has come up with a really good approach to 
>> generics, much better than the prior proposals.
>>
>> -Mike
>>
>> P.S. If there is one thing that piqued my interest about this thread it 
>> was Geoff Speicher's suggestion of a "generic" keyword, assuming type 
>> inference could be addressed. That approach would be even easier to reason 
>> about than the current proposal, I think.  That said, the current proposal 
>> is very good if type inference can not be addressed in Geoff Speicher's 
>> suggestion.
>>
>> On Wednesday, July 22, 2020 at 8:02:55 PM UTC-4 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 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/fbc7a998-0e8d-46ff-a59a-23a63a8a5aa0n%40googlegroups.com.

Re: [go-nuts] A few thoughts on type parameters

[Denis Cheremisov]

>  I think "[type T]" is slightly clearer than "[T any]".

Code with `[T any]` is much easier to read at least for me.

среда, 5 августа 2020 г. в 11:07:59 UTC+3, Jan Mercl: 

> On Tue, Aug 4, 2020 at 6:07 AM 'Carla Pfaff' via golang-nuts
>  wrote:
>
> > On Tuesday, 4 August 2020 at 00:34:12 UTC+2 ben...@gmail.com wrote:
>
> > I'm sure it would quickly become a well-known idiom, just like people 
> know that "error" is "interface{Error() string}" or "fmt.Stringer" is 
> "interface{String() string}".
>
> I'm sure some people will never write `any` instead of `interface{}`
> and I can prove it ;-)
>
> > Actually the current use of "interface{}" is a bit odd because it is the 
> only case where an interface is commonly used as an anonymous type rather 
> than by an identifier.
>
> It's not the only place. It does not happen often, but interface type
> literals other than interface{} appear in real code and for good
> reasons. It's an overkill to name a thing that will be referenced by
> name only once.
>
> > I assume that in current Go the empty interface is supposed to be an 
> ugly duckling to discourage its overuse, but in a world with type 
> parameters it will play an important role as the unbounded constraint and 
> it should deserve its own identifier.
>
> It's not supposed to be anything special whatsoever. Just like number
> zero or an empty set is not some kind of an exception. It's just you
> cannot have any reasonable set theory without it.
>
> BTW: I assume number 42 to be special, though not for math. Can I have
> a nice Unicode point for it, so I can write it nicely all over my
> example code?
>
> > Most Go programmers want to be type safe and avoid casting.
>
> Go programmers do avoid casting because Go has no casting. That word
> or its stem doesn't even appear in the language specs.
>

-- 
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/4d2f667c-41d8-4ea7-9817-d08026bc0aa6n%40googlegroups.com.

Re: [go-nuts] Re: Why we don't have simple throws error statement

[Denis Cheremisov]

There are two major issues with Go error handling:


   1. It is not strict enough, i.e. the compiler cannot ensure error check
   2. It is not consistent enough.

In the first you can easily ignore an error and the compiler will let you 
go further. In the second, you can both

*if err := doSomething(); err != nil {*
*}*

and

*v, err := returnSomething()*
*if err != nil {*
*}*

*or err* would do this better for sure

*doSomething() or err {*
*}*

and

*v := returnSomething() or err {*
*}*

воскресенье, 2 августа 2020 г. в 03:55:59 UTC+3, skinne...@gmail.com: 

> I do not consider error handling an issue but then again I tend to either 
> use the Doit() err{} or MustDoit(){} panic and then use  DI (dependency 
> injection implemented by interface) for error-handling so that I can get an 
> email when we get a new error. So then it would be 
> MustDoit(errorHandler("ConIo")){} 
>
> Actually I suppose it is an issue, I do not do error handling in Go, but 
> my preprocessor converts it to Go. Go error handling can do anything, the 
> implementation may not be clear and that may be the real problem. We can 
> change it by improving the language or by training programmers on 
> recognizing useful abstractions, may need both.
>
>
> On Saturday, August 1, 2020 at 1:31:54 PM UTC-5 Ian Lance Taylor wrote:
>
>> On Sat, Aug 1, 2020 at 10:59 AM  wrote: 
>> > 
>> > Has anyone ever tallied the number of different forum threads related 
>> to changing Go error handling ? 
>> > The current method is obviously a vexing issue to many Go users, and 
>> > It seems silly that this issue has never been resolved by the Go team 
>> beyond maintaining the status quo... despite, IMHO, several good 
>> alternatives that have been suggested on this very forum. 
>>
>> There have been many alternatives suggested, but none of them have 
>> been clearly better. 
>>
>> I recently wrote a brief overview at https://golang.org/issue/40432. 
>>
>> 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/7973c178-cd2c-49cd-b995-4e245f91822cn%40googlegroups.com.

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

[Denis Cheremisov]

> 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 is highly questionable assumption. Context outside is obviously 
superior:

   - Your assumption just does not work. Imagine a generic function like 
   *os.Open*, it cannot provide really sensible and easy to read context.
   - Context outside means finer control, the annotation can tell exactly 
   what you meant. With *try* you only can achieve the same with numerous 
   tiny functions of one use and this payload hugely overweights these *if 
   err != nil*

I really glad this strange proposal was rejected. I was voting for better 
error handling, but I meant better error handling, not this nonsense. I 
would like to have something that will not allow to pass error handling by 
mistake, not the way to save 3 or 2 lines of code in one place just to have 
additional 6 lines to achieve the same error annotations detais.




среда, 29 июля 2020 г. в 01:01:34 UTC+3, mbohu...@gmail.com: 

> 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.

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

[Denis Cheremisov]

I actually mean something different. The bad with *any* in builtins is 
there will be questions "why you use interface{}" if there's builtin *any?*", 
etc. I mean these will be different AST nodes, there will be

*type GenericAny struct {*
*Name *ast.Lit*

*}*
and

*type Generic struct {*
*Name *ast.Lit*
*Type *ast.Ident*
*}*

the type system then will see if there's type *any* in a scope and will 
replace it with a type info node for that type, otherwise, *interface{}* 
will be used. A bit ugly and I am anything but sure if they will be really 
happy with that. Still a variant.
воскресенье, 26 июля 2020 г. в 02:11:18 UTC+3, Carla Pfaff: 

> I don't see why it should be in the grammar. Just a regular type alias for 
> interface{} in the builtin scope, a regular predeclared identifier. It 
> wouldn't break anyone's code. If someone already has an 'any' type or 
> variable in their package their version shadows the builtin one, and they 
> can still use interface{} as a generic type constraint. At least that's how 
> it works with other builtin type aliases like 'rune': 
> https://play.golang.org/p/KRX3fIBV9qW

-- 
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/bc7dd36b-0d5a-4ade-aa41-344ba7fb1bacn%40googlegroups.com.

[go-nuts] Re: How can I fork a module that uses /internal ?

[Denis Cheremisov]

As soon as I understand you can just keep their module name in `go.mod` and 
that's it.

воскресенье, 26 июля 2020 г. в 03:46:15 UTC+3, brad.be...@gmail.com: 

> Hi folks.  I was unable to find a good answer online already.  The closest 
> I found was 
> https://stackoverflow.com/questions/14323872/using-forked-package-import-in-go
>  which 
> suggests using the replace directive in go.mod.
>
> I am using Go 1.14, with all projects located outside of GOPATH.
>
> My exact situation:  I've forked https://github.com/sclevine/agouti to 
> https://github.com/Bradbev/agouti.  Originally I renamed all instances of 
> "sclevine" to "Bradbev" - this works, but doesn't feel right.  Presumably 
> future PR's will be a hassle due to the import changes.
> I'm trying to fix it locally before pushing up.  So, what I have locally is
> 1) A new module agout_test, which contains "replace 
> github.com/bradbev/agouti => ../agouti" in go.mod so that my test project 
> references a local copy
> 2) A local copy of bradbev/agouti at ../agouti.
>
> Without changes (ie, import paths ARE rewritten), this works.  When I 
> change my local agouti imports back to "sclevine", and add "replace 
> github.com/sclevine/agouti => github.com/bradbev/agouti" to 
> ../agouti/go.mod, my test complains with:
>
> ✘-1 ~/development/gomod/agouti_test 
>
> 22:51 $ go build main.go && ./main
>
> ../agouti/selectable.go:5:2: use of internal package 
> github.com/sclevine/agouti/internal/element not allowed
>
> ../agouti/multiselection.go:3:8: use of internal package 
> github.com/sclevine/agouti/internal/target not allowed
>
>
> This suggests to me that the replace directive is working, but is being 
> disallowed for "/internal" packages.  
>
> What is the correct way to fork this module please?
>
> Thanks,
> Brad
>

-- 
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/4dca8bec-f7e9-4963-ae2a-e3e277cdada6n%40googlegroups.com.

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

[Denis Cheremisov]

Btw, it `any` suffix can be a part of grammar, I mean something like

*GenericParam = Lit [',' Lit]* 'any' | Lit [',' Lit]* Ident*

where *any* can be replaced with an actual *any* if there's one in a scope.

воскресенье, 26 июля 2020 г. в 00:47:17 UTC+3, Denis Cheremisov: 

> Great catch! I would say I really like it!
>
> суббота, 25 июля 2020 г. в 23:37:39 UTC+3, Carla Pfaff: 
>
>> I know it's common to have no constraints, but "[Elem any]" is even one 
>> character shorter than "[type Elem]". I rewrote the function signatures 
>> from slices.go2 in this way, and it doesn't feel painful. This already 
>> works on the go2go playground: https://go2goplay.golang.org/p/IQV5LTAIuDr
>>
>> On Saturday, 25 July 2020 at 22:22:24 UTC+2 Ian Lance Taylor wrote:
>>
>>> On Sat, Jul 25, 2020 at 11:47 AM 'Carla Pfaff' via golang-nuts 
>>>  wrote: 
>>> > 
>>> > To expand on my post: 
>>> > It would be very consistent with the structure of regular parameter 
>>> lists. Just like every parameter in a regular parameter list must have a 
>>> type (with the exception of multiple consecutive parameters having the same 
>>> type), every type parameter in a type parameter list must have a 
>>> constraint. 
>>>
>>> That is certainly true. 
>>>
>>> But it is also true, based on experiments writing generic code, that 
>>> the majority of type parameters have no constraints. That is 
>>> particularly true for type parameters of generic types. So while it 
>>> would be possible to require people to always explicitly write a 
>>> constraint, it seems painful to force people to always write something 
>>> that is almost never needed. 
>>>
>>> Note that in this way constraints on type parameters are different 
>>> from types of regular parameters. It makes no sense to speak of a 
>>> regular parameter with no type. It's entirely reasonable, even 
>>> common, to speak of a type parameter with no constraint. 
>>>
>>> Ian 
>>>
>>>
>>> > On Saturday, 25 July 2020 at 20:26:37 UTC+2 Carla Pfaff wrote: 
>>> >> 
>>> >> I just discovered the experiment to make the "type" keyword optional 
>>> in certain cases on the dev.go2go branch. The commit message says: 
>>> >> 
>>> >> --- 
>>> >> Experiment: Make "type" keyword optional in generic type declarations 
>>> when 
>>> >> it is clear that we can't have an array type declaration. This is the 
>>> case 
>>> >> when we have one the following: 
>>> >> 
>>> >> - more than one type parameter 
>>> >> - a type parameter with a constraint 
>>> >> - a trailing comma in the type parameter list 
>>> >> -- 
>>> >> 
>>> >> If the "type" keyword is not necessary if a constraint is present, 
>>> then why not make a constraint mandatory and get rid of the "type" keyword 
>>> in type parameter lists altogether? 
>>> >> 
>>> >> Before: 
>>> >> 
>>> >> func Filter[type Elem](...) 
>>> >> func Map[Elem1, Elem2](...) 
>>> >> func Max[Elem constraints.Ordered](...) 
>>> >> 
>>> >> After: 
>>> >> 
>>> >> func Filter[Elem interface{}](...) 
>>> >> func Map[Elem1, Elem2 interface{}](...) 
>>> >> func Max[Elem constraints.Ordered](...) 
>>> >> 
>>> >> "interface{}" may be a little bulky, especially it since it is 
>>> usually used for the simple cases. But if there was a short type alias for 
>>> "interface{}" like "any" it can look good: 
>>> >> 
>>> >> type any = interface{} 
>>> >> 
>>> >> func Filter[Elem any](...) 
>>> >> func Map[Elem1, Elem2 any](...) 
>>> >> func Max[Elem constraints.Ordered](...) 
>>> >> 
>>> > -- 
>>> > 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. 
>>> > To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/d7a9fe08-73bb-487b-ba2a-6766560f3b03n%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/6d81692a-9e5a-4674-8358-b5a5a25f6b47n%40googlegroups.com.

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

[Denis Cheremisov]

Great catch! I would say I really like it!

суббота, 25 июля 2020 г. в 23:37:39 UTC+3, Carla Pfaff: 

> I know it's common to have no constraints, but "[Elem any]" is even one 
> character shorter than "[type Elem]". I rewrote the function signatures 
> from slices.go2 in this way, and it doesn't feel painful. This already 
> works on the go2go playground: https://go2goplay.golang.org/p/IQV5LTAIuDr
>
> On Saturday, 25 July 2020 at 22:22:24 UTC+2 Ian Lance Taylor wrote:
>
>> On Sat, Jul 25, 2020 at 11:47 AM 'Carla Pfaff' via golang-nuts 
>>  wrote: 
>> > 
>> > To expand on my post: 
>> > It would be very consistent with the structure of regular parameter 
>> lists. Just like every parameter in a regular parameter list must have a 
>> type (with the exception of multiple consecutive parameters having the same 
>> type), every type parameter in a type parameter list must have a 
>> constraint. 
>>
>> That is certainly true. 
>>
>> But it is also true, based on experiments writing generic code, that 
>> the majority of type parameters have no constraints. That is 
>> particularly true for type parameters of generic types. So while it 
>> would be possible to require people to always explicitly write a 
>> constraint, it seems painful to force people to always write something 
>> that is almost never needed. 
>>
>> Note that in this way constraints on type parameters are different 
>> from types of regular parameters. It makes no sense to speak of a 
>> regular parameter with no type. It's entirely reasonable, even 
>> common, to speak of a type parameter with no constraint. 
>>
>> Ian 
>>
>>
>> > On Saturday, 25 July 2020 at 20:26:37 UTC+2 Carla Pfaff wrote: 
>> >> 
>> >> I just discovered the experiment to make the "type" keyword optional 
>> in certain cases on the dev.go2go branch. The commit message says: 
>> >> 
>> >> --- 
>> >> Experiment: Make "type" keyword optional in generic type declarations 
>> when 
>> >> it is clear that we can't have an array type declaration. This is the 
>> case 
>> >> when we have one the following: 
>> >> 
>> >> - more than one type parameter 
>> >> - a type parameter with a constraint 
>> >> - a trailing comma in the type parameter list 
>> >> -- 
>> >> 
>> >> If the "type" keyword is not necessary if a constraint is present, 
>> then why not make a constraint mandatory and get rid of the "type" keyword 
>> in type parameter lists altogether? 
>> >> 
>> >> Before: 
>> >> 
>> >> func Filter[type Elem](...) 
>> >> func Map[Elem1, Elem2](...) 
>> >> func Max[Elem constraints.Ordered](...) 
>> >> 
>> >> After: 
>> >> 
>> >> func Filter[Elem interface{}](...) 
>> >> func Map[Elem1, Elem2 interface{}](...) 
>> >> func Max[Elem constraints.Ordered](...) 
>> >> 
>> >> "interface{}" may be a little bulky, especially it since it is usually 
>> used for the simple cases. But if there was a short type alias for 
>> "interface{}" like "any" it can look good: 
>> >> 
>> >> type any = interface{} 
>> >> 
>> >> func Filter[Elem any](...) 
>> >> func Map[Elem1, Elem2 any](...) 
>> >> func Max[Elem constraints.Ordered](...) 
>> >> 
>> > -- 
>> > 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. 
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/d7a9fe08-73bb-487b-ba2a-6766560f3b03n%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/cecba51d-1718-44e0-b088-3d6b5f194c09n%40googlegroups.com.

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

[Denis Cheremisov]

I look at what Carla did write and it feels ... good. I don't know, it may 
be not for everyone, but for me [T any] looks cleaner than [type T]. 
Probably I see `[` and understand this is generic params, then `T` and I 
immediately understand this is how the generic type denoted. A final touch, 
I would seriously consider this idea.

суббота, 25 июля 2020 г. в 23:22:24 UTC+3, Ian Lance Taylor: 

> On Sat, Jul 25, 2020 at 11:47 AM 'Carla Pfaff' via golang-nuts
>  wrote:
> >
> > To expand on my post:
> > It would be very consistent with the structure of regular parameter 
> lists. Just like every parameter in a regular parameter list must have a 
> type (with the exception of multiple consecutive parameters having the same 
> type), every type parameter in a type parameter list must have a constraint.
>
> That is certainly true.
>
> But it is also true, based on experiments writing generic code, that
> the majority of type parameters have no constraints. That is
> particularly true for type parameters of generic types. So while it
> would be possible to require people to always explicitly write a
> constraint, it seems painful to force people to always write something
> that is almost never needed.
>
> Note that in this way constraints on type parameters are different
> from types of regular parameters. It makes no sense to speak of a
> regular parameter with no type. It's entirely reasonable, even
> common, to speak of a type parameter with no constraint.
>
> Ian
>
>
> > On Saturday, 25 July 2020 at 20:26:37 UTC+2 Carla Pfaff wrote:
> >>
> >> I just discovered the experiment to make the "type" keyword optional in 
> certain cases on the dev.go2go branch. The commit message says:
> >>
> >> ---
> >> Experiment: Make "type" keyword optional in generic type declarations 
> when
> >> it is clear that we can't have an array type declaration. This is the 
> case
> >> when we have one the following:
> >>
> >> - more than one type parameter
> >> - a type parameter with a constraint
> >> - a trailing comma in the type parameter list
> >> --
> >>
> >> If the "type" keyword is not necessary if a constraint is present, then 
> why not make a constraint mandatory and get rid of the "type" keyword in 
> type parameter lists altogether?
> >>
> >> Before:
> >>
> >> func Filter[type Elem](...)
> >> func Map[Elem1, Elem2](...)
> >> func Max[Elem constraints.Ordered](...)
> >>
> >> After:
> >>
> >> func Filter[Elem interface{}](...)
> >> func Map[Elem1, Elem2 interface{}](...)
> >> func Max[Elem constraints.Ordered](...)
> >>
> >> "interface{}" may be a little bulky, especially it since it is usually 
> used for the simple cases. But if there was a short type alias for 
> "interface{}" like "any" it can look good:
> >>
> >> type any = interface{}
> >>
> >> func Filter[Elem any](...)
> >> func Map[Elem1, Elem2 any](...)
> >> func Max[Elem constraints.Ordered](...)
> >>
> > --
> > 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.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/d7a9fe08-73bb-487b-ba2a-6766560f3b03n%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/1075c5dd-d876-46db-8385-d2fae9c53366n%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[Denis Cheremisov]

Lesser and greater signs never were a good choice. They were chosen because 
of C syntax restrictions. Go creators would do *slice[T]* (or may be just 
*[T]*), *map[K,V]*,* chan[T]*, etc if they had generics in mind. Because, 
if you have managed not to notice it, Go barely inherited anything from C. 
Know why? Because C is full of unfortunate decisions. Some people love it 
because this is their first relatively low level language and they like the 
power. Me, who wrote assembler before C, have never been impressed with it: 
its syntax is not particularly pleasant to read and I rather felt the lack 
of power with it. It is not only hard to read, it is just plain weird. 
Consider this:

a * b;

What is this? May be an expression? Or a declaration, pointer a of type b?

So, please stop using languages with syntax inherited from C as a 
benchmark. The C is a result of the lack of planning, a chaotic 
development. And this usage of comparison operators as brackets is an 
unfortunate combination of circumstances.
Luckily, there was a planning in Go, with some initial limitations which 
causes a bit of pain nowdays, still much better than C and even more so 
than C++. I am really glad they don't consider these < monstrosities: I 
tried Scala and as much as I dislike the language in general their [] 
things for generic parameters left very good impression. I really like they 
borrowed the idea.

четверг, 23 июля 2020 г. в 00:22:26 UTC+3, sah...@naman.ms: 

> With angled brackets, do we really need the colon or dot on both sides?  
> Wouldn't it be enough to just have it on the left to eliminate the parse 
> time ambiguities?  Like f<:int> or f<.int>?
>
> On Wed, 22 Jul 2020, 22:46 Евгений Кошевой,  wrote:
>
>> Maybe something like this:
>> using <.Type.>
>> func f(T<.int.>)
>> struct{ T<.int.> }
>> interface{ T<.int.> }
>> []T<.int.>{}
>>
>> среда, 22 июля 2020 г. в 01:12:32 UTC+3, Steven Blenkinsop: 
>>
>>> On Tue, Jul 21, 2020 at 3:12 PM, Michal Strba  
>>> wrote:
>>>
 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.

>>>
>>> That's not true in Go. Conversions look like function calls:
>>>
>>>   y := f(x)
>>>
>>> could be a conversion or a function call, depending on whether f is a 
>>> function or a type. If you need to use type parameters on f, the same 
>>> parsing problems present themselves whether it's a parameterized type or a 
>>> type parametric function.
>>>
 -- 
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/a6a400ee-b9e2-4f30-a82d-a39ad8f5aaafn%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/f5e27f11-3dc4-4caa-adc4-4f4619a50cfcn%40googlegroups.com.

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

[Denis Cheremisov]

func XGenericFunction(x X) …

пятница, 17 июля 2020 г. в 01:25:29 UTC+3, kortschak: 

> On Thu, 2020-07-16 at 13:44 -0700, jpap wrote:
> > Notwithstanding a concise unambiguous alternative, I would rather
> > type parameters "stick out" so they are easily identified when
> > visually scanning through code.
>
> func ᕙ(⇀ X ↼‶)ᕗ GenericFunction(x X) ...
>
>
>

-- 
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/c44e256d-23df-4b11-a487-e221c684d886n%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[Denis Cheremisov]

The big argument I always found less and greater signs to be not visually 
distinctive enough, at least with fonts I am using. [ and ] are larger and 
I was really happy with them in Scala although I dislike the language in 
general. 
Seriously though, the real big argument is [] are already used with in two 
of three generic types ([]T, map[K]V, only is chan T is different). And 
there's a huge argument, with the performance of simple tools like gofmt, 
etc.

среда, 15 июля 2020 г. в 23:21:38 UTC+3, frave...@gmail.com: 

> On Jul 15, 2020, at 2:48 PM, Ian Lance Taylor  wrote:
> > 
> > More seriously, though, let's look closely at Robert's example:
> > 
> > a, b = w < x, y > (z)
>
> TBH, I think a big argument in favor of square brackets over angle 
> brackets is that they ascend above the center line in most typefaces, which 
> makes them much more visually distinct from the shorter operators and many 
> lowercase letters. This is similar to parens and curly braces while still 
> being visually distinct from both.
>
> As something that is essentially a metaparameter which is similar to, but 
> distinct in function to the arguments in parens, there's a lot of good 
> consistency going on there that I personally find easier to visually scan 
> without syntax highlighting than I do angle brackets. But that could be 
> just me, and it does depend on typeface, so take it with whatever grains of 
> salt you need to.
>
>
> - 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/1c240cb4-82c7-4abb-b00f-970102bc746an%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[Denis Cheremisov]

Great! Those multiple parenthesis were a beat on unredable side indeed, and 
I always was in the pro-square party as I always found less and greater 
signs to be unreadable. As much as I disliked Scala in general I liked 
their generic syntax. This is a really good news Go will have the same.

среда, 15 июля 2020 г. в 00:56:01 UTC+3, gri: 

> We have received a variety of feedback on the generics draft design 
> 
>  
> (blog ). Thanks to everyone 
> who took the time to read it, play with generics code in the playground 
> , file issues, and send us their thoughts.
>
> Not unexpectedly, many people raised concerns about the syntax, 
> specifically the choice of parentheses for type parameter declarations and 
> generic type and function instantiations.
>
> A typical computer keyboard provides four easily accessible pairs of 
> single-character symmetrical "brackets": parentheses ( and ), square 
> brackets [ and ], curly braces { and }, and angle brackets < and >. Go uses 
> curly braces to delineate code blocks, composite literals, and some 
> composite types, making it virtually impossible to use them for generics 
> without severe syntactic problems. Angle brackets require unbounded parser 
> look-ahead or type information in certain situations (see the end of this 
> e-mail for an example). This leaves us with parentheses and square 
> brackets. Unadorned square brackets cause ambiguities in type declarations 
> of arrays and slices, and to a lesser extent when parsing index 
> expressions. Thus, early on in the design, we settled on parentheses as 
> they seemed to provide a Go-like feel and appeared to have the fewest 
> problems.
>
> As it turned out, to make parentheses work well and for 
> backward-compatibility, we had to introduce the type keyword in type 
> parameter lists. Eventually, we found additional parsing ambiguities in 
> parameter lists, composite literals, and embedded types which required more 
> parentheses to resolve them. Still, we decided to proceed with parentheses 
> in order to focus on the bigger design issues.
>
> The time has come to revisit this early decision. If square brackets alone 
> are used to declare type parameters, the array declaration
>
> type A [N]E
>
> cannot be distinguished from the generic type declaration
>
> type A[N] E
>
> But if we are comfortable with the extra type keyword, the ambiguity 
> disappears:
>
> type A[type N] E
>
> (When we originally dismissed square brackets, the type keyword was not 
> yet on the table.)
>
> Furthermore, the ambiguities that arise with parentheses appear not to 
> arise with square brackets. Here are some examples where extra parentheses 
> are not needed with square brackets:
>
> using () using []
>
> func f((T(int))  func f(T[int])
>
> struct{ (T(int)) }   struct{ T[int] }
>
> interface{ (T(int)) }interface{ T[int] }
>
> [](T(int)){} []T[int]{}
>
> To test this better understanding, and to get a feel for this alternative 
> notation, we will begin to make changes to our prototype implementation 
> such that it accepts either parentheses or square brackets (only one or the 
> other) in a generic Go package. Those changes will first appear as commits 
> to the dev.go2go branch 
> , and eventually 
> in the playground .
>
> If square brackets don't lead to unforeseen issues, we have another fully 
> explored notation to choose from, which will allow us to make a more 
> informed decision.
>
> - gri, iant
>
> PS: For ambiguities with angle brackets consider the assignment
>
> a, b = w < x, y > (z)
>
> Without type information, it is impossible to decide whether the 
> right-hand side of the assignment is a pair of expressions
>
> (w < x), (y > (z))
>
> or whether it is a generic function invocation that returns two result 
> values
>
> (w)(z)
>
> In Go, type information is not available at compile time. For instance, in 
> this case, any of the identifiers may be declared in another file that has 
> not even been parsed yet.
>
>

-- 
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/dfb0b9c3-753e-4db0-822c-b73ef3225111n%40googlegroups.com.

Re: [go-nuts] My small app executes within 400μs but the exit happens in about 0.16s

[Denis Cheremisov]

Thank you, this helped a lot, strace showed there was a background activity 
looking for *gopackgesdriver *file. The problem was I had 

packages.Load(nil, "std")


in one of my modules run in an init(). Changed this piece into on-demand logic 
and now


real0m0,010s
user0m0,001s
sys 0m0,009s



воскресенье, 5 июля 2020 г., 3:45:34 UTC+3 пользователь Kurtis Rader 
написал:
>
> On Sat, Jul 4, 2020 at 5:24 PM Denis Cheremisov  > wrote:
>
>> I have a small app like
>>
>> func main() {
>> start := time.Now()
>> …
>> fmt.Println(time.Since(start))
>> }
>>
>> where output is ≈400μs but the actual time is about 0.16s, I mean
>>
>
> I can't reproduce and since it is really rare to see anyone report 
> something like this it is most likely a quirk of your system. Also, when 
> reporting issues of this nature you should include the go version and 
> information about the platform such as the OS. I would start by using 
> `strace -ttt -o strace.out app-name` to see if there are any syscalls that 
> are taking longer than expected. If that doesn't reveal an obvious culprit 
> then the time is probably external to your program.
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/a92c8cf9-a812-427a-bcbb-128e228f02b5o%40googlegroups.com.

[go-nuts] My small app executes within 400μs but the exit happens in about 0.16s

[Denis Cheremisov]

Hi!

I have a small app like


func main() {
start := time.Now()

…

fmt.Println(time.Since(start))
}

where output is ≈400μs but the actual time is about 0.16s, I mean

$ time app-name 

real 0m0,156s
user 0m0,238s
sys 0m0,054s

Profiling collects nothing (it is expected with ≈400μs of course). Is there 
a method to detect what holds this for so long?

-- 
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/68154c33-5444-45a9-bd03-30629e4b08d8o%40googlegroups.com.

Re: [go-nuts] Generic syntax suggestions

[Denis Cheremisov]

PS

Also, *[]T* and *map[K]V* does not look consistent, so I don''t think this 
> is a true valid reason:

I didn't mean they are inconsistent. They just don't look consistent at the 
first glance. 

суббота, 20 июня 2020 г., 19:06:14 UTC+3 пользователь Denis Cheremisov 
написал:
>
> I like it. Poor VSCode users will suffer from the current approach and all 
> these ((() – this thing can't even highlight types of function 
> parameters. Your variant is a lot (I mean a LOT) more readable 
>
> Also, *[]T* and *map[K]V* does not look consistent, so I don''t think 
> this is a true valid reason:
>
> In Go we write []int, not [slice int], and we write map[int]int, not [map 
>> int int].
>>
>
> суббота, 20 июня 2020 г., 11:02:05 UTC+3 пользователь Wu Kulics написал:
>>
>> Thank you for your reply. I did mention this suggestion on [Github](
>> https://github.com/golang/go/issues/36457) before, but then everyone's 
>> focus was on the backend.
>>
>>  
>>
>> In the previous map and slice examples, [slice int] and [map int int] are 
>> just for reference. I think this syntax is very similar to []int and 
>> map[int]int, which is very suitable for everyone to understand the generic 
>> design of Go, we do not need to change the previous syntax.
>>
>>  
>>
>> The design of identifier(type T) will lead to too many () in the end, 
>> especially when defining the receiver function. This change in readability 
>> undermines Go's original goal. We still want to see simple and clear code 
>> on Go, not many ().
>>
>>  
>>
>> I have studied in detail the generic design of Go proposed by others. So 
>> far, [identifier T] is the only solution that to avoid <>, without 
>> increasing the number of characters, without adding keywords, without 
>> ambiguity, without reducing readability, without increase the workload, and 
>> continues the original grammatical design.
>>
>>  
>>
>> I hope this design can attract enough attention, or at least it can cause 
>> some discussion.
>>
>>  
>>
>> *发件人**: *Ian Lance Taylor 
>> *日期**: *2020年6月20日 星期六 上午3:03
>> *收件人**: *Wu Kulics 
>> *抄送**: *"golan...@googlegroups.com" 
>> *主题**: *Re: [go-nuts] Generic syntax suggestions
>>
>>  
>>
>> On Fri, Jun 19, 2020 at 10:24 AM Wu Kulics  wrote:
>>
>> Dear Go Design Team:
>>
>>  
>>
>> Recently I explored a new generic syntax in the [Feel](
>> https://github.com/kulics-works/feel 
>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkulics-works%2Ffeel=02%7C01%7C%7C44033f9f1d204eb2584d08d814838012%7C84df9e7fe9f640afb435%7C1%7C0%7C637281902309384232=VGm2RHSKdaISaqpa01InrUlDndPWWaEvAVlUlbcNLB8%3D=0>)
>>  
>> language that I designed, because Feel borrowed a lot of grammar from Go, 
>> so this Generic syntax may also have some reference value for Go.
>>
>>  
>>
>> The `identifier` problem is that it conflicts with comparison 
>> operators and also bit operators, so I don't agree with this design.
>>
>>  
>>
>> Scala's `identifier[T]` has a better look and feel than the previous 
>> design, but after resolving the above conflict, it has a new conflict with 
>> the index design `identifier[index]`.
>>
>> For this reason, the index design of Scala has been changed to 
>> `identifier(index)`. This does not work well for languages that already use 
>> `[]` as an index.
>>
>>  
>>
>> In Go's draft, it was declared that generics use `(type T)`, which will 
>> not cause conflicts, because `type` is a keyword, but the compiler still 
>> needs more judgment when it is called to resolve the` 
>> identifier(type)(params) `. Although it is better than the above solutions, 
>> it still does not satisfy me.
>>
>>  
>>
>> By chance, I remembered the special design of method invocation in OC, 
>> which gave me inspiration for a new design.
>>
>>  
>>
>> What if we put the identifier and the generic as a whole and put them in 
>> `[]` together?
>>
>> We can get the `[identifier T]`. This design does not conflict with the 
>> index, because it must have at least two elements, separated by spaces.
>>
>> When there are multiple generics, we can write `[identifier T V]` like 
>> this, and it will not conflict with the existing design.
>>
>>  
>>
>> Substituting this design into Go, we can get the following example.
>>
>> E.g.
>>
>> [image: 手机屏幕的截图 描述已自动生成]
>

Re: [go-nuts] Generic syntax suggestions

[Denis Cheremisov]

I like it. Poor VSCode users will suffer from the current approach and all 
these ((() – this thing can't even highlight types of function 
parameters. Your variant is a lot (I mean a LOT) more readable 

Also, *[]T* and *map[K]V* does not look consistent, so I don''t think this 
is a true valid reason:

In Go we write []int, not [slice int], and we write map[int]int, not [map 
> int int].
>

суббота, 20 июня 2020 г., 11:02:05 UTC+3 пользователь Wu Kulics написал:
>
> Thank you for your reply. I did mention this suggestion on [Github](
> https://github.com/golang/go/issues/36457) before, but then everyone's 
> focus was on the backend.
>
>  
>
> In the previous map and slice examples, [slice int] and [map int int] are 
> just for reference. I think this syntax is very similar to []int and 
> map[int]int, which is very suitable for everyone to understand the generic 
> design of Go, we do not need to change the previous syntax.
>
>  
>
> The design of identifier(type T) will lead to too many () in the end, 
> especially when defining the receiver function. This change in readability 
> undermines Go's original goal. We still want to see simple and clear code 
> on Go, not many ().
>
>  
>
> I have studied in detail the generic design of Go proposed by others. So 
> far, [identifier T] is the only solution that to avoid <>, without 
> increasing the number of characters, without adding keywords, without 
> ambiguity, without reducing readability, without increase the workload, and 
> continues the original grammatical design.
>
>  
>
> I hope this design can attract enough attention, or at least it can cause 
> some discussion.
>
>  
>
> *发件人**: *Ian Lance Taylor >
> *日期**: *2020年6月20日 星期六 上午3:03
> *收件人**: *Wu Kulics >
> *抄送**: *"golan...@googlegroups.com " <
> golan...@googlegroups.com >
> *主题**: *Re: [go-nuts] Generic syntax suggestions
>
>  
>
> On Fri, Jun 19, 2020 at 10:24 AM Wu Kulics  > wrote:
>
> Dear Go Design Team:
>
>  
>
> Recently I explored a new generic syntax in the [Feel](
> https://github.com/kulics-works/feel 
> )
>  
> language that I designed, because Feel borrowed a lot of grammar from Go, 
> so this Generic syntax may also have some reference value for Go.
>
>  
>
> The `identifier` problem is that it conflicts with comparison operators 
> and also bit operators, so I don't agree with this design.
>
>  
>
> Scala's `identifier[T]` has a better look and feel than the previous 
> design, but after resolving the above conflict, it has a new conflict with 
> the index design `identifier[index]`.
>
> For this reason, the index design of Scala has been changed to 
> `identifier(index)`. This does not work well for languages that already use 
> `[]` as an index.
>
>  
>
> In Go's draft, it was declared that generics use `(type T)`, which will 
> not cause conflicts, because `type` is a keyword, but the compiler still 
> needs more judgment when it is called to resolve the` 
> identifier(type)(params) `. Although it is better than the above solutions, 
> it still does not satisfy me.
>
>  
>
> By chance, I remembered the special design of method invocation in OC, 
> which gave me inspiration for a new design.
>
>  
>
> What if we put the identifier and the generic as a whole and put them in 
> `[]` together?
>
> We can get the `[identifier T]`. This design does not conflict with the 
> index, because it must have at least two elements, separated by spaces.
>
> When there are multiple generics, we can write `[identifier T V]` like 
> this, and it will not conflict with the existing design.
>
>  
>
> Substituting this design into Go, we can get the following example.
>
> E.g.
>
> [image: 手机屏幕的截图 描述已自动生成]
>
>  
>
> This looks very clear.
>
>  
>
> Another benefit of using `[]` is that it has some inheritance from Go's 
> original Slice and Map design, and will not cause a sense of fragmentation.
>
> [image: 手机屏幕的截图 描述已自动生成]
>
>  
>
> We can make a more complicated example
>
> [image: 手机屏幕截图 描述已自动生成]
>
>  
>
> This example still maintains a relatively clear effect, and at the same 
> time has a small impact on compilation.
>
>  
>
> I have implemented and tested this design in Feel and it works well. 
>
>  
>
> I think Go’s current generic syntax will eventually render the code too 
> many `()`, so that the readability is destroyed when coding, and the goal 
> of simplicity is lost.
>
>  
>
> In addition to the way of `[identifier T]`, I have also tested the syntax 
> of ``. After doing some special processing on `>>`, it can 
> also avoid ambiguity. This is closer to the mainstream `identifier` 
> grammar, and it is easier to lower the learning threshold for users of 
> other languages.
>
>  
>
> Thank you very much for reading this 

Re: [go-nuts] [generics] bring contracts back

[Denis Cheremisov]

Got one: https://rakyll.org/generics-proposal/

At the very bottom of the page, a person wrote a strange code 

func Do(type T io.Reader)(r T) {
switch r.(type) {
case io.ReadCloser:
fmt.Println("ReadCloser")
}
}
prog.go2:19:9: r (variable of type T) is not an interface type


and has a strange question.

They are strange, but still valid: why can't I cast an interface to another 
one. Because this is a source of confusion, two kinds of interfaces where 
one is called interface but is not actually an interface.

So, points are:


   - 
   
   Two kind of interfaces appear, where one cannot be used anywhere except 
   a contract: https://go2goplay.golang.org/p/rYOD-n_mV9U
   - 
   
   There's a confusion between an interface used as a contract and an 
   interface. People think if they have interface contract their type is an 
   interface (it is not of course): 
   
https://www.reddit.com/r/golang/comments/hamaxm/few_things_on_generics_go_the_unwritten_parts/fv66zp8/?context=3.
 
   A brainless example of course, but still an example.
   - 
   
   If fields will be allowed to be a part of contract (limiting allowed 
   types to structs having some set of fields of certain types) the difference 
   between interfaces and interfaces for contracts will grow even bigger. I 
   see lots of questions like fron ones who just start learning Go "why can't 
   I use a pure field interface as a function parameter type?"
   - 
   
   contract also meant a built-in mechanism of type bounding, with 
   interfaces you need to promote each type exclusively, the increased 
   signature size is the consequence of this. Remeber, with contracts you may 
   put a constraint on each of the parameter types and with an interface you 
   should write them all.
   - 
   
   interface flood. There's a possibility to use them as an 
   variable/paremeter/return value type although they are only needed for a 
   generic contract.
   


пятница, 19 июня 2020 г., 0:07:45 UTC+3 пользователь Denis Cheremisov 
написал:
>
> > clear feedback on earlier versions of the design draft that contracts
> could be hard to understand.
>
> Yeah, sure. Now expect lots of materials throughout the web explaining 
> "this part is for interface that is not supposed to be in a runtime but for 
> compile time constraints". You understand better than me albeit these 
> concepts (interfaces and contractrs) has a lot in common they are not the 
> same. At last, take your language as an example: it shines as a glue 
> between services and its set of primitives (goroutines, channels, full 
> async) is what made it so successful in this domain. But you won't try to 
> use it for serious Linux kernel module. You won't even try these primitives 
> for GUI development (which also has asynchronous nature) because they have 
> a huge overweight for the task.
>
>
>
> PS I am afraid these people I were listening also want <> 
>
>
> четверг, 18 июня 2020 г., 1:11:22 UTC+3 пользователь Ian Lance Taylor 
> написал:
>>
>> On Wed, Jun 17, 2020 at 9:58 AM Denis Cheremisov 
>>  wrote: 
>> > 
>> > IMO a groups of constraints are horrible with interfaces 
>> > 
>> > type CommonResponse(type E) interface { 
>> > GetError() E 
>> > } 
>> > 
>> > type CommonError interface { 
>> > GetCode() int32 
>> > } 
>> > 
>> > func IsOK(type R CommonResponse(E), E CommonError)(r R) bool { 
>> > switch r.GetError().GetCode() { 
>> > case 0, 200, 201: 
>> > return true 
>> > default: 
>> > return false 
>> > } 
>> > } 
>> > 
>> > vs 
>> > 
>> > constract CommmonResponse(R, E) { 
>> > R GetError() E 
>> > E GetCode() int32 
>> > } 
>> > 
>> > func IsOK(type R, E CommonResponse)(r R) bool { 
>> > switch r.GetError().GetCode() { 
>> > case 0, 200, 201: 
>> > return true 
>> > default: 
>> > return false 
>> > } 
>> > } 
>> > 
>> > That trickery with commas to express dependcy of types is hard 
>>
>>
>> I think there is no question that complex cases are more difficult to 
>> express using parameterized interfaces as constraints. 
>>
>> But the overall change to the language seems to be simpler.  There was 
>> clear feedback on earlier versions of the design draft that contracts 
>> could be hard to understand.  And with parameterized interfaces as 
>> constraints it is still possible to express the complex cases, albeit 
>> in a more complicated way.  It's OK if complicated are hard to 
>> express, as long as they remain possible. 
>>
>> 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/22dd5894-f2de-451d-ab78-4c90b0da0b92o%40googlegroups.com.

Re: [go-nuts] [generics] bring contracts back

[Denis Cheremisov]

> clear feedback on earlier versions of the design draft that contracts
could be hard to understand.

Yeah, sure. Now expect lots of materials throughout the web explaining 
"this part is for interface that is not supposed to be in a runtime but for 
compile time constraints". You understand better than me albeit these 
concepts (interfaces and contractrs) has a lot in common they are not the 
same. At last, take your language as an example: it shines as a glue 
between services and its set of primitives (goroutines, channels, full 
async) is what made it so successful in this domain. But you won't try to 
use it for serious Linux kernel module. You won't even try these primitives 
for GUI development (which also has asynchronous nature) because they have 
a huge overweight for the task.



PS I am afraid these people I were listening also want <> 


четверг, 18 июня 2020 г., 1:11:22 UTC+3 пользователь Ian Lance Taylor 
написал:
>
> On Wed, Jun 17, 2020 at 9:58 AM Denis Cheremisov 
> > wrote: 
> > 
> > IMO a groups of constraints are horrible with interfaces 
> > 
> > type CommonResponse(type E) interface { 
> > GetError() E 
> > } 
> > 
> > type CommonError interface { 
> > GetCode() int32 
> > } 
> > 
> > func IsOK(type R CommonResponse(E), E CommonError)(r R) bool { 
> > switch r.GetError().GetCode() { 
> > case 0, 200, 201: 
> > return true 
> > default: 
> > return false 
> > } 
> > } 
> > 
> > vs 
> > 
> > constract CommmonResponse(R, E) { 
> > R GetError() E 
> > E GetCode() int32 
> > } 
> > 
> > func IsOK(type R, E CommonResponse)(r R) bool { 
> > switch r.GetError().GetCode() { 
> > case 0, 200, 201: 
> > return true 
> > default: 
> > return false 
> > } 
> > } 
> > 
> > That trickery with commas to express dependcy of types is hard 
>
>
> I think there is no question that complex cases are more difficult to 
> express using parameterized interfaces as constraints. 
>
> But the overall change to the language seems to be simpler.  There was 
> clear feedback on earlier versions of the design draft that contracts 
> could be hard to understand.  And with parameterized interfaces as 
> constraints it is still possible to express the complex cases, albeit 
> in a more complicated way.  It's OK if complicated are hard to 
> express, as long as they remain possible. 
>
> 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/50d5375c-1698-4006--9ac3a6c84d1do%40googlegroups.com.

Re: [go-nuts] [generics] why struct fields-based constraints were banned?

[Denis Cheremisov]

It would be much less troublesome if you would keep using contracts instead 
of this interface insanity.

четверг, 18 июня 2020 г., 3:18:05 UTC+3 пользователь Ian Lance Taylor 
написал:
>
> On Wed, Jun 17, 2020 at 10:05 AM Denis Cheremisov 
> > wrote: 
> > 
> > I can't get why struct based constraints were banned. struct is a kind 
> of types in Go and a wish to only allow them having some field is valid. 
>
> I'm not sure I would say that they were banned, it's just that we 
> haven't seen a good way to fit them into the notion of interface types 
> as constraints. 
>
> It's not clear how important this is.  It's not clear how often this 
> really comes up in practice. 
>
> 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/eccb23d1-5d14-4508-b52e-eb715511bbb2o%40googlegroups.com.

[go-nuts] Re: [generics] Replace () with <> or other character

[Denis Cheremisov]

Not all languages use <> for parametric parametrism. I tried lots of 
variants and my favorite is [] from Scala (I don't like Scala, BTW).


четверг, 18 июня 2020 г., 11:15:16 UTC+3 пользователь Nathanael Curin 
написал:
>
> An argument for this is also that (all ?) languages that use generics use 
> <>. It might make learning just easier for new Go developers that have 
> experience from generics-compatible languages.
>
> Dimas -> Resembling other languages in some ways is not necessarily a bad 
> thing, if the idea behind it makes sense.
>
> Le mercredi 17 juin 2020 18:36:10 UTC+2, Charles Crete a écrit :
>>
>> Based on the new proposal, having the type parameters as () seems very 
>> confusing, as now 3 things in a row use ():
>> - Type parameters
>> - Function parameters/arguments
>> - Return tuple
>>
>> This results in code like (from the draft):
>> func Stringify(type T Stringer)(s []T) (ret []string) {
>>   for _, v := range s {
>> ret = append(ret, v.String())
>>   }
>>   return ret
>> }
>>
>> Instead, using <> similar to other languages, makes it easier to visual 
>> parse:
>> func Stringify(s []T) (ret []string) {
>>   for _, v := range s {
>> ret = append(ret, v.String())
>>   }
>>   return ret
>> }
>>
>> This can also apply to type definitions:
>> type Vector []T
>>
>> To summarize:
>> - Having 3 times () in a row makes it confusing to visual parse
>> - The type keyword is not necessary
>> - Using <> would make it friendly (and easier to recognize)
>>
>

-- 
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/72815259-77ba-4ac8-b5c3-1e4943a08d47o%40googlegroups.com.

[go-nuts] Re: [generics] (again). Type inference is somewhat weak

[Denis Cheremisov]

Better example. A method to request for exacly one element from the gRPC 
bistream. A thing that is frequently needed when there're lots of bistream 
gRPC methods.

https://go2goplay.golang.org/p/RQEyhRRQb0p

IRL I would need to call it as

resp, err := proto.ReadOne(service.Service_MethodClient, 
service.MethodRequest, service.MethodResponse)(ctx, client.Method, 
{
…
})

instead of simple to read

resp, err := proto.ReadOne(ctx, client.Method, {
…
})

среда, 17 июня 2020 г., 19:43:35 UTC+3 пользователь Denis Cheremisov 
написал:
>
> https://go2goplay.golang.org/p/ObL79WVHDjw
>
> Need to write types explicitly although all the info needed is easily 
> accessible:
>
> fmt.Println(IsOK(*commonResponse, *commonError)(r))
>
> What I am sure is I will keep using a code generator instead of this 
> monstrosity. 
>

-- 
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/6bfdcc4c-dca8-4051-b89c-65274c2f6982o%40googlegroups.com.

[go-nuts] Re: [generics] gRPC bistream quantization

[Denis Cheremisov]

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/4ec07617-5c11-4e01-b4b4-e16e1e652d25o%40googlegroups.com.

[go-nuts] [generics] gRPC bistream quantization

[Denis Cheremisov]

Another question about generics, a HOWTODO one: I am bored to death writing 
methods what would send one request and get one response from a gRPC 
bistream. Decided to try a draft 2 against a generic approach to the task.

My final attempt which I still can't 
compile: https://go2goplay.golang.org/p/z8XUKua3k-J

Where is the mistake?


-- 
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/67c95f3e-a70e-4cb5-ac8f-d886ac32ee39o%40googlegroups.com.

[go-nuts] Re: [generics] bring contracts back

[Denis Cheremisov]

oops, an infitie loop in the As implementation, now the right one:

https://go2goplay.golang.org/p/5NnZBnmIC96

среда, 17 июня 2020 г., 21:55:52 UTC+3 пользователь Denis Cheremisov 
написал:
>
> There's an advantage though, for rather narrow cases though: reuse of 
> interfaces:
>
> https://go2goplay.golang.org/p/HJr3QIzgQuX
>
> среда, 17 июня 2020 г., 19:58:08 UTC+3 пользователь Denis Cheremisov 
> написал:
>>
>> IMO a groups of constraints are horrible with interfaces
>>
>> type CommonResponse(type E) interface {
>> GetError() E
>> }
>>
>> type CommonError interface {
>> GetCode() int32
>> }
>>
>> func IsOK(type R CommonResponse(E), E CommonError)(r R) bool {
>> switch r.GetError().GetCode() {
>> case 0, 200, 201:
>> return true
>> default:
>> return false
>> }
>> }
>>
>> vs
>>
>> constract CommmonResponse(R, E) {
>> R GetError() E
>> E GetCode() int32
>> }
>>
>> func IsOK(type R, E CommonResponse)(r R) bool {
>> switch r.GetError().GetCode() {
>> case 0, 200, 201:
>> return true
>> default:
>> return false
>> }
>> }
>>
>> That trickery with commas to express dependcy of types is hard
>>
>

-- 
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/965c8563-8535-41e8-9f31-cc75dbe2b5c5o%40googlegroups.com.

[go-nuts] Re: [generics] bring contracts back

[Denis Cheremisov]

There's an advantage though, for rather narrow cases though: reuse of 
interfaces:

https://go2goplay.golang.org/p/HJr3QIzgQuX

среда, 17 июня 2020 г., 19:58:08 UTC+3 пользователь Denis Cheremisov 
написал:
>
> IMO a groups of constraints are horrible with interfaces
>
> type CommonResponse(type E) interface {
> GetError() E
> }
>
> type CommonError interface {
> GetCode() int32
> }
>
> func IsOK(type R CommonResponse(E), E CommonError)(r R) bool {
> switch r.GetError().GetCode() {
> case 0, 200, 201:
> return true
> default:
> return false
> }
> }
>
> vs
>
> constract CommmonResponse(R, E) {
> R GetError() E
> E GetCode() int32
> }
>
> func IsOK(type R, E CommonResponse)(r R) bool {
> switch r.GetError().GetCode() {
> case 0, 200, 201:
> return true
> default:
> return false
> }
> }
>
> That trickery with commas to express dependcy of types is hard
>

-- 
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/a93996df-d66c-4fd2-85a8-3a7e9d709050o%40googlegroups.com.

[go-nuts] [generics] why struct fields-based constraints were banned?

[Denis Cheremisov]

I can't get why struct based constraints were banned. struct is a kind of 
types in Go and a wish to only allow them having some field is valid. 

-- 
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/71f82a41-329b-4acd-8729-8f02f4fc9918o%40googlegroups.com.

[go-nuts] [generics] bring contracts back

[Denis Cheremisov]

IMO a groups of constraints are horrible with interfaces

type CommonResponse(type E) interface {
GetError() E
}

type CommonError interface {
GetCode() int32
}

func IsOK(type R CommonResponse(E), E CommonError)(r R) bool {
switch r.GetError().GetCode() {
case 0, 200, 201:
return true
default:
return false
}
}

vs

constract CommmonResponse(R, E) {
R GetError() E
E GetCode() int32
}

func IsOK(type R, E CommonResponse)(r R) bool {
switch r.GetError().GetCode() {
case 0, 200, 201:
return true
default:
return false
}
}

That trickery with commas to express dependcy of types is hard

-- 
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/4e25a228-4c96-44ba-b33a-bbde3460ea2ao%40googlegroups.com.

[go-nuts] Re: [generics]Use "<>" to declare template would be better than "()"

[Denis Cheremisov]

Better for who? You? 
I would to love to see `[]` instead of `()`, but `<>` are horrible to read 
IMO.

среда, 17 июня 2020 г., 19:36:09 UTC+3 пользователь hao luo написал:
>
> The creator:
>
> Hi, I am extremely interested in and eager for golang's generics, and I 
> have read the updated draft. 
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#acknowledgements
>
> I think use "<>" to declare template's type would be more appropriate.
>
> Original in the draft:
>
> func Print(type T)(s []T) {
>   // same as above}
>
>
> My opinions:
>
> func Print(s []T) {
>   // same as above}
>
>
> The reason:
> 1. More clear to discriminate and generics to normal funcs and type.
> 2. Use "<>" to declare type for generic code.
> 3. Use "()" to declare running params.
>
> Wish you can give a thought to it.
>
> hao
>

-- 
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/2412c48b-19bd-4b31-900c-704a044eb479o%40googlegroups.com.

[go-nuts] Re: [generics] Replace () with <> or other character

[Denis Cheremisov]

>
> makes it easier to visual parse
>
Are you sure? It may be a personal thing, but "visual parsing" of these <<< 
really annoys me, I would prefer `[]`, but I like `()` more than `<>`. In 
addition, a good IDE (not that well known overhyped editor on steroids) 
will highlight these fragments, so not really a problem.


среда, 17 июня 2020 г., 19:36:10 UTC+3 пользователь Charles Crete написал:
>
> Based on the new proposal, having the type parameters as () seems very 
> confusing, as now 3 things in a row use ():
> - Type parameters
> - Function parameters/arguments
> - Return tuple
>
> This results in code like (from the draft):
> func Stringify(type T Stringer)(s []T) (ret []string) {
>   for _, v := range s {
> ret = append(ret, v.String())
>   }
>   return ret
> }
>
> Instead, using <> similar to other languages, makes it easier to visual 
> parse:
> func Stringify(s []T) (ret []string) {
>   for _, v := range s {
> ret = append(ret, v.String())
>   }
>   return ret
> }
>
> This can also apply to type definitions:
> type Vector []T
>
> To summarize:
> - Having 3 times () in a row makes it confusing to visual parse
> - The type keyword is not necessary
> - Using <> would make it friendly (and easier to recognize)
>

-- 
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/2f79e6cb-1575-43f2-b213-eb0a59a46853o%40googlegroups.com.

[go-nuts] [generics] (again). Type inference is somewhat weak

[Denis Cheremisov]

https://go2goplay.golang.org/p/ObL79WVHDjw

Need to write types explicitly although all the info needed is easily 
accessible:

fmt.Println(IsOK(*commonResponse, *commonError)(r))

What I am sure is I will keep using a code generator instead of this 
monstrosity. 

-- 
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/bd9090eb-b728-488b-89e2-2bdebea0687do%40googlegroups.com.

Re: [go-nuts] Need advice on AST formatting

[Denis Cheremisov]

The answer was simple: 

var fset token.FileSet – wrong

fset := token.NewFileSet() – right


вторник, 22 октября 2019 г., 11:20:38 UTC+3 пользователь Michel Levieux 
написал:
>
> Hi Denis,
>
> In a project of my own I encountered the same issue. This program moves a 
> go project to another location, then it remembers imports (that are 
> necessary), exported types, functions and package-scope values (var / 
> const) and maps them in the original go project to the newly created one. 
> The original goal of this program is to move packages from other packages, 
> while leaving everything compatible as is. Everything almost works now but 
> in practice, all my code has a strange look, like function/type definitions 
> are all stuck with one another, with no lines in between.
>
> If anyone has suggestions or ideas, please let us know!
>
> Thanks to all of you for your time.
>
> Le ven. 18 oct. 2019 à 00:11, Denis Cheremisov  > a écrit :
>
>> Hi!
>>
>> I have a utility that parses Go files into AST , makes some changes on 
>> the tree (import paths) and format it back into the Go source code, in the 
>> original file.
>>
>> The problem is I am using format.Node function from this 
>> <https://golang.org/pkg/go/format/> package. The formatting this 
>> function applies to the AST is very similar to what gofmt does but it is 
>> not identical. 
>>
>> Example.
>>
>> The original file may look like this
>>
>> // +build !windows
>>
>> package main
>>
>> import (
>> ""
>> )
>>
>> func main() {}
>>
>> And the result will look like
>>
>> // +build !windows
>> package main
>>
>> import (
>> ""
>> )
>>
>> func main() {}
>>
>> See the 2nd line of the original: it is blank. And it disappears in the 
>> result. And I don't touch neither the Package token of the AST, neither the 
>> leading comment.
>>
>> What AST into source printer can I use instead to preserve that blank 
>> line?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/50b2e8fe-e017-403e-a2d8-f44cfd86f20a%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/50b2e8fe-e017-403e-a2d8-f44cfd86f20a%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/f1461f3b-c872-47f5-b67f-5cb5838b8d70%40googlegroups.com.

[go-nuts] Need advice on AST formatting

[Denis Cheremisov]

Hi!

I have a utility that parses Go files into AST , makes some changes on the 
tree (import paths) and format it back into the Go source code, in the 
original file.

The problem is I am using format.Node function from this 
 package. The formatting this function 
applies to the AST is very similar to what gofmt does but it is not 
identical. 

Example.

The original file may look like this

// +build !windows

package main

import (
""
)

func main() {}

And the result will look like

// +build !windows
package main

import (
""
)

func main() {}

See the 2nd line of the original: it is blank. And it disappears in the 
result. And I don't touch neither the Package token of the AST, neither the 
leading comment.

What AST into source printer can I use instead to preserve that blank line?

-- 
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/50b2e8fe-e017-403e-a2d8-f44cfd86f20a%40googlegroups.com.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Denis Cheremisov]

> I think many people like the proposal but are not vocal about it.

Emoji count should reflect that "silent majority" better than comments. We 
have larger negative count on `try` and overwhelming 1293 vs 154 positive 
count on leaving it as is. People who care generally dislike poorly thought 
`try`, that's it.

воскресенье, 30 июня 2019 г., 15:47:54 UTC+3 пользователь 
pierr...@gmail.com написал:
>
> Indeed.
>
> I think many people like the proposal but are not vocal about it. It is 
> not perfect but it *does *bring value to the table if you read the 
> proposal in its entirety and think about how you would use/could use it in 
> a real life scenario.
>
> I do *decorate *errors a lot, I do care about the *control flow* (I have 
> been along time user of *defer *for error handling and find it not 
> magical or ugly but fitting beautifully with the language), which are the 
> main topics people are complaining about... And I think it actually works 
> fine in those situations.
>
> In fact, the try() approach has started growing on me as I write code now, 
> I feel it would help in quite a few situations and simplify, not in a 
> drastic way, but subtle and valuable one.
>
> My 2c.
>
> Le samedi 29 juin 2019 21:31:19 UTC+2, Henrik Johansson a écrit :
>
>> I for one like the try proposal. It removes much of my gripes with the 
>> verbosity of error handling.
>>
>> I think that it will become more readable than explicit error handling 
>> quite fast. Note that it is still explicit, if you don't use the try 
>> notation the error can be handled as it is now or ignored as it sometimes 
>> is now.
>>
>> I have a feeling that there is a quite large "silent majority" that 
>> pretty much agrees with me.
>>
>> On Sat, Jun 29, 2019, 21:18 Denis Cheremisov  
>> wrote:
>>
>>> And prepare for wider audience in shitty “try” proposal after 1 July.
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golan...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%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/49411503-e6f1-4be7-ae39-57b55e782779%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Proposal: try function constructor

[Denis Cheremisov]

Pooof

Are you serious?

-- 
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/92c9f0fe-b955-48da-b20e-362a3d426482%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Denis Cheremisov]

And prepare for wider audience in shitty “try” proposal after 1 July.

-- 
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/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Denis Cheremisov]

The “try” proposal is unpopular: 246 dislikes vs 186 likes.

And aforementioned one is highly popular with more than a thousand likes and 
the like/dislike ration is reaching 8 (actual numbers are 1147 likes vs 148 
dislikes).

And you must understand the specific: you are solving relatively hard problems 
developing language called Go with low mistake cost and we are solving simple 
problems with a DSL called Go but our mistake cost is much higher than yours.

Now, there was an excellent example: 

info := try(try(os.File(fileName)).Stat())

We are having file descriptor leak here.

I thought you are trying to be as practical as possible making a language with 
such a retarded yet somehow usable type system in XXI. But this recent proposal 
raises some suspicions...

-- 
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/40cc7e81-1679-4691-a1a1-f34584ea0929%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] GoAWK: an AWK interpreter written in Go

[Denis Cheremisov]

>  - also enable normal go program to use awk scripts

probably this  is better tool for the 
case

суббота, 24 ноября 2018 г., 5:43:22 UTC+3 пользователь Tong Sun написал:
>
>
>
> On Saturday, November 17, 2018 at 12:44:57 PM UTC-5, Ben Hoyt wrote:
>>
>>
>> https://benhoyt.com/writings/goawk/ 
>> 
>>
>> It's pretty much a toy project, not being used for anything real, but it 
>> seems to be in a good shape. Feedback welcome!
>>
>
> Hope there are future plans to extend it so that, 
>
> - people can define user function in go and use it in goawk 
> 
>  handling, 
> as kty... has pointed out. 
> - also enable normal go program to use awk scripts
>
> thx
>
>

-- 
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] How to deal with binaries compilation with go modules enabled?

[Denis Cheremisov]

oops, gave link to a dup, here's a right 
one: https://github.com/golang/go/issues/27380

четверг, 30 августа 2018 г., 22:06:36 UTC+3 пользователь Denis Cheremisov 
написал:
>
> Filled a new issue: https://github.com/golang/go/issues/27381
> Please let me know if a title is too weird, I am about as good with them 
> as with variable names :)
>
> четверг, 30 августа 2018 г., 21:35:21 UTC+3 пользователь Sam Whited 
> написал:
>>
>> FWIW, I have the same issue (I have to unset GO111MODULE before 
>> attempting to fetch a binary or before building Go) and there appear to be 
>> several comments on the closed issue suggesting that this is still a 
>> problem: 
>>
>> https://golang.org/issues/26639 
>>
>> I just tested this on tip (currently devel +360771e422) but haven't dug 
>> in further. 
>>
>> —Sam 
>>
>> On Thu, Aug 30, 2018, at 13:29, Denis Cheremisov wrote: 
>> > strange, still the same 
>> > 
>> > $ go get -x -u golang.org/x/tools/cmd/goimports 
>> > go: cannot find main module; see 'go help modules' 
>> > 
>> > I am using 
>> > 
>> > $ go version 
>> > go version go1.11 linux/amd64 
>> > 
>> > with 
>> > 
>> > export GO111MODULE=on 
>> > 
>> > 
>> > 
>> > четверг, 30 августа 2018 г., 18:21:45 UTC+3 пользователь Ian Davis 
>> написал: 
>> > > 
>> > > 
>> > > On Thu, 30 Aug 2018, at 3:37 PM, Denis Cheremisov wrote: 
>> > > 
>> > > Hi! 
>> > > With Go 1.10 and earlier one can install binaries via regular `go 
>> get`, `go 
>> > > get golang.org/x/tools/cmd/goimports` 
>> <http://golang.org/x/tools/cmd/goimports> for instance. 
>> > > It doesn't work with Go modules enabled: 
>> > > 
>> > > $ go get golang.org/x/tools/cmd/goimports 
>> > > go: cannot find main module; see 'go help modules' 
>> > > 
>> > > this is an obvious usability downgrade. I wonder if someone knows 
>> about 
>> > > some sort of replacement for the functionality? 
>> > > 
>> > > 
>> > > It should still work (and does for me). 
>> > > 
>> > > Can you try go get -x -u golang.org/x/tools/cmd/goimports and see 
>> what 
>> > > the output prints about the problem. 
>> > > 
>> > > 
>> > > 
>> > 
>> > -- 
>> > 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. 
>>
>>
>> -- 
>> Sam Whited 
>> s...@samwhited.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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How to deal with binaries compilation with go modules enabled?

[Denis Cheremisov]

Filled a new issue: https://github.com/golang/go/issues/27381
Please let me know if a title is too weird, I am about as good with them as 
with variable names :)

четверг, 30 августа 2018 г., 21:35:21 UTC+3 пользователь Sam Whited написал:
>
> FWIW, I have the same issue (I have to unset GO111MODULE before attempting 
> to fetch a binary or before building Go) and there appear to be several 
> comments on the closed issue suggesting that this is still a problem: 
>
> https://golang.org/issues/26639 
>
> I just tested this on tip (currently devel +360771e422) but haven't dug in 
> further. 
>
> —Sam 
>
> On Thu, Aug 30, 2018, at 13:29, Denis Cheremisov wrote: 
> > strange, still the same 
> > 
> > $ go get -x -u golang.org/x/tools/cmd/goimports 
> > go: cannot find main module; see 'go help modules' 
> > 
> > I am using 
> > 
> > $ go version 
> > go version go1.11 linux/amd64 
> > 
> > with 
> > 
> > export GO111MODULE=on 
> > 
> > 
> > 
> > четверг, 30 августа 2018 г., 18:21:45 UTC+3 пользователь Ian Davis 
> написал: 
> > > 
> > > 
> > > On Thu, 30 Aug 2018, at 3:37 PM, Denis Cheremisov wrote: 
> > > 
> > > Hi! 
> > > With Go 1.10 and earlier one can install binaries via regular `go 
> get`, `go 
> > > get golang.org/x/tools/cmd/goimports` 
> <http://golang.org/x/tools/cmd/goimports> for instance. 
> > > It doesn't work with Go modules enabled: 
> > > 
> > > $ go get golang.org/x/tools/cmd/goimports 
> > > go: cannot find main module; see 'go help modules' 
> > > 
> > > this is an obvious usability downgrade. I wonder if someone knows 
> about 
> > > some sort of replacement for the functionality? 
> > > 
> > > 
> > > It should still work (and does for me). 
> > > 
> > > Can you try go get -x -u golang.org/x/tools/cmd/goimports and see 
> what 
> > > the output prints about the problem. 
> > > 
> > > 
> > > 
> > 
> > -- 
> > 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. 
>
>
> -- 
> Sam Whited 
> s...@samwhited.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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How to deal with binaries compilation with go modules enabled?

[Denis Cheremisov]

strange, still the same

$ go get -x -u golang.org/x/tools/cmd/goimports 
go: cannot find main module; see 'go help modules'

I am using 

$ go version
go version go1.11 linux/amd64

with

export GO111MODULE=on



четверг, 30 августа 2018 г., 18:21:45 UTC+3 пользователь Ian Davis написал:
>
>
> On Thu, 30 Aug 2018, at 3:37 PM, Denis Cheremisov wrote:
>
> Hi!
> With Go 1.10 and earlier one can install binaries via regular `go get`, `go 
> get golang.org/x/tools/cmd/goimports` for instance.
> It doesn't work with Go modules enabled:
>
> $ go get golang.org/x/tools/cmd/goimports
> go: cannot find main module; see 'go help modules'
>
> this is an obvious usability downgrade. I wonder if someone knows about 
> some sort of replacement for the functionality?
>
>
> It should still work (and does for me).
>
> Can you try go get -x -u golang.org/x/tools/cmd/goimports and see what 
> the output prints about the problem.
>
>
>

-- 
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] How to deal with binaries compilation with go modules enabled?

[Denis Cheremisov]

Hi!
With Go 1.10 and earlier one can install binaries via regular `go get`, `go 
get golang.org/x/tools/cmd/goimports` for instance.
It doesn't work with Go modules enabled:

$ go get golang.org/x/tools/cmd/goimports
go: cannot find main module; see 'go help modules'

this is an obvious usability downgrade. I wonder if someone knows about 
some sort of replacement for the functionality?

-- 
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: [go/types] Implements doesn't work for types from different packages when the interface signature has types from the package where the interface lies.

[Denis Cheremisov]

This library are not supposed to be used that way. Importer should be used 
directly:

package main

import (
   "fmt"
   "go/importer"
   "go/types"
)

var imprt = importer.For("source", nil)

func main() {
   p1, err := imprt.Import("awesome/pkg1")
   if err != nil {
  panic(err)
   }
   p2, err := imprt.Import("awesome/pkg2")
   if err != nil {
  panic(err)
   }

   iface := 
p1.Scope().Lookup("Interface").(*types.TypeName).Type().(*types.Named).Underlying().(*types.Interface)
   impl1 := p1.Scope().Lookup("Implementation1").Type()
   fmt.Printf("%s\n", impl1.(*types.Named).Method(0).Name())
   impl2 := p2.Scope().Lookup("Implementation2").Type()
   fmt.Println("Implementation1 implements Interface", types.Implements(impl1, 
iface))
   fmt.Println("Implementation2 implements Interface", types.Implements(impl2, 
iface))
}

Введите код...

The problem though ASTs are not cached. I copied implementation of importer 
from go/internal/srcimporter and extended it with caching (I need ASTs 
besides *type.Package for style checks)

суббота, 5 мая 2018 г., 2:04:34 UTC+3 пользователь Denis Cheremisov написал:
>
> Hi!
>
> I am writing a special linting-like piece of code and struggle dealing 
> with the Implements <https://golang.org/pkg/go/types/#Implements> that 
> doesn't work for my configuration. I made a simplified testing example to 
> show the issue:
>
>
>- I have package speaker with interface Speaker and its default 
>implementation.
>
>package speaker
>type Default struct{}
>func (Default) Speak(Arg) string {
>   return "speak"
>}
>type Arg struct{}
>type Speaker interface {
>   Speak(Arg) string
>}
>
>- 
>
>Now, I have another package, with "Russian speaker":
>
>
>package ru
>import "awesome/speaker"
>type Russian struct{}
>func (Russian) Speak(speaker.Arg) string {
>   return "говорить"
>}
>
>- 
>
>An finally I have a main package
>
>
>package main
>
>import (
>   "fmt"
>   "go/ast"
>   "go/importer"
>   "go/parser"
>   "go/token"
>   "go/types"
>   "path/filepath"
>   "runtime"
>)
>
>func getPath() string {
>   fpcs := make([]uintptr, 5)
>   frameIter := runtime.CallersFrames(fpcs[:runtime.Callers(1, fpcs)])
>   var frames []runtime.Frame
>   frame, more := frameIter.Next()
>   frames = append(frames, frame)
>   if !more {
>  panic("stack frames must exists for a call")
>   }
>   return filepath.Dir(frame.File)
>}
>
>func getTypes(path ...string) *types.Package {
>   path = append([]string{getPath()}, path...)
>   fullpath := filepath.Join(path...)
>   fset := token.NewFileSet()
>   pkgs, err := parser.ParseDir(fset, fullpath, nil, parser.ParseComments)
>   if err != nil {
>  panic(err)
>   }
>   for _, pkg := range pkgs {
>  config := {
> IgnoreFuncBodies: false,
> FakeImportC:  false,
> Error:nil,
> Importer: importer.Default(),
> Sizes:nil,
> DisableUnusedImportCheck: false,
>  }
>  info := types.Info{
> Types: map[ast.Expr]types.TypeAndValue{},
> Defs:  map[*ast.Ident]types.Object{},
> Uses:  map[*ast.Ident]types.Object{},
>  }
>  var files []*ast.File
>  for _, file := range pkg.Files {
> files = append(files, file)
>  }
>  typeInfo, err := config.Check(fullpath, fset, files, )
>  if err != nil {
> panic(err)
>  }
>  return typeInfo
>   }
>   return nil
>}
>
>func main() {
>   mainPkg := getTypes("speaker")
>   ruPkg := getTypes("ru")
>
>   iface := 
> mainPkg.Scope().Lookup("Speaker").Type().Underlying().(*types.Interface)
>   dflt := mainPkg.Scope().Lookup("Default").Type()
>   russian := ruPkg.Scope().Lookup("Russian").Type()
>
>   fmt.Println(types.Implements(dflt, iface))
>   fmt.Println(types.Implements(russian, iface))
>}
>
>
> Output is:
> true
> false
>
> The output is true-true without the argument. Is it a feature or a bug? 
> How can I walk around 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [go/types] Implements doesn't work for types from different packages when the interface signature has types from the package where the interface lies.

[Denis Cheremisov]

I meant true-false is not expected behaviour, true-true is what I would 
love to see.

-- 
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] [go/types] Implements doesn't work for types from different packages when the interface signature has types from the package where the interface lies.

[Denis Cheremisov]

Hi!

I am writing a special linting-like piece of code and struggle dealing with 
the Implements  that doesn't 
work for my configuration. I made a simplified testing example to show the 
issue:


   - I have package speaker with interface Speaker and its default 
   implementation.
   
   package speaker
   type Default struct{}
   func (Default) Speak(Arg) string {
  return "speak"
   }
   type Arg struct{}
   type Speaker interface {
  Speak(Arg) string
   }
   
   - 
   
   Now, I have another package, with "Russian speaker":
   
   
   package ru
   import "awesome/speaker"
   type Russian struct{}
   func (Russian) Speak(speaker.Arg) string {
  return "говорить"
   }
   
   - 
   
   An finally I have a main package
   
   
   package main
   
   import (
  "fmt"
  "go/ast"
  "go/importer"
  "go/parser"
  "go/token"
  "go/types"
  "path/filepath"
  "runtime"
   )
   
   func getPath() string {
  fpcs := make([]uintptr, 5)
  frameIter := runtime.CallersFrames(fpcs[:runtime.Callers(1, fpcs)])
  var frames []runtime.Frame
  frame, more := frameIter.Next()
  frames = append(frames, frame)
  if !more {
 panic("stack frames must exists for a call")
  }
  return filepath.Dir(frame.File)
   }
   
   func getTypes(path ...string) *types.Package {
  path = append([]string{getPath()}, path...)
  fullpath := filepath.Join(path...)
  fset := token.NewFileSet()
  pkgs, err := parser.ParseDir(fset, fullpath, nil, parser.ParseComments)
  if err != nil {
 panic(err)
  }
  for _, pkg := range pkgs {
 config := {
IgnoreFuncBodies: false,
FakeImportC:  false,
Error:nil,
Importer: importer.Default(),
Sizes:nil,
DisableUnusedImportCheck: false,
 }
 info := types.Info{
Types: map[ast.Expr]types.TypeAndValue{},
Defs:  map[*ast.Ident]types.Object{},
Uses:  map[*ast.Ident]types.Object{},
 }
 var files []*ast.File
 for _, file := range pkg.Files {
files = append(files, file)
 }
 typeInfo, err := config.Check(fullpath, fset, files, )
 if err != nil {
panic(err)
 }
 return typeInfo
  }
  return nil
   }
   
   func main() {
  mainPkg := getTypes("speaker")
  ruPkg := getTypes("ru")
   
  iface := 
mainPkg.Scope().Lookup("Speaker").Type().Underlying().(*types.Interface)
  dflt := mainPkg.Scope().Lookup("Default").Type()
  russian := ruPkg.Scope().Lookup("Russian").Type()
   
  fmt.Println(types.Implements(dflt, iface))
  fmt.Println(types.Implements(russian, iface))
   }
   
   
Output is:
true
false

The output is true-true without the argument. Is it a feature or a bug? How 
can I walk around 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.
For more options, visit https://groups.google.com/d/optout.


package.tar.xz
Description: Binary data

[go-nuts] [dep] is it planned to integrate `go get` and future `go dep`?

[Denis Cheremisov]

Hi!
I struggled a couple of days ago with an issue caused by the fact the *go 
get* is not aware of dependencies defined by the current *dep*, which I am 
using for the development purposes.

*dep* sticked to fixed https://github.com/antlr/antlr4 version (latest, 
v4.7 released in march 2017), while there were changes since that and *go 
get* downloads the latest master and it led to compilation errors.
I solved this issue pushing part of the vendor directory with antlr4 into 
the my repo.

Will the *go get* use *dep* beneath to download dependencies?

-- 
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.