well, `go get something` without a GOPATH existing or from an arbitrary
directory is a popular use case.
I assume, `go mod` is not ready for it yet, but will be at time of enabling it
by default.
It’s still in early preview.
but currently absence of this functionality stops me from
FWIW I've published some ideas about how contracts and interface types
could be partially unified, and contracts significantly simplified,
which I think is quite pertinent to the above discussion.
Doc here:
https://gist.github.com/rogpeppe/45f5a7578507989ec4ba5ac639ae2c69
On 1 September 2018
On Sat, Sep 1, 2018, 11:43 AM Vasily Korytov wrote:
> Hi,
>
> I've experimented with GO111MODULE preview in Go 1.11 release, two things
> to note so far:
> 1. go mod vendor pulled in vendor folder the .travis.yml file which
> apparently I don't want there (govendor filters it by default)
>
> 2.
On Saturday, 1 September 2018 20:29:31 UTC+2, Axel Wagner wrote:
>
> I don't understand what you are trying to say. You assert that there
> wouldn't be a type-error, but you don't actually justify that.
>
There are 2 examples, both are (to me) intuitive suggestions and not the
result of a
On Saturday, 1 September 2018 19:26:00 UTC+2, Scott Cotton wrote:
>
>
>
> On Saturday, 1 September 2018 18:26:29 UTC+2, Axel Wagner wrote:
>>
>> On Fri, Aug 31, 2018 at 6:57 PM Scott Cotton wrote:
>>
>>> My intuition is that interfaces would be obsolete -- and that's a very
>>> good thing.
>>>
On Saturday, 1 September 2018 18:26:29 UTC+2, Axel Wagner wrote:
>
> On Fri, Aug 31, 2018 at 6:57 PM Scott Cotton > wrote:
>
>> My intuition is that interfaces would be obsolete -- and that's a very
>> good thing.
>>
>
> They wouldn't. You can't have heterogeneous lists with contracts. For
>
On Fri, Aug 31, 2018 at 6:57 PM Scott Cotton wrote:
> My intuition is that interfaces would be obsolete -- and that's a very
> good thing.
>
They wouldn't. You can't have heterogeneous lists with contracts. For
example, say you have a Reader contract:
contract Reader(r R) {
var (
n
Struct literals don't require keys, but `go vet` will complain about
unkeyed fields for a struct type from another package. It won't complain
about unkeyed fields for a struct from the same package.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
Maybe you are running out of sockets due to the missing close on the response
body after read
--
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
It seem appropriate for both here since (it's a Go build issue) and
there. I have asked at google-appengine-go, but it appears that it is a
thing, probably due to a run of `go vet -composites` on the code prior
to build. It's not clear if that is still done.
On Sat, 2018-09-01 at 01:04 -0700, T L
You can ask this question here:
https://groups.google.com/forum/#!forum/google-appengine-go
https://groups.google.com/forum/#!forum/google-appengine
On Thursday, August 30, 2018 at 8:29:31 PM UTC-4, kortschak wrote:
>
> It is my recollection that GAE requires that struct literals have
> explicit
Got help on the matter.
Problem is with echo itself. After v3.2.2 they have dropped the letter v
from tags.
--
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
echo has a version v3.1.0-rc.1 with a not standard format. That's why it
works with v3.0.0+incompatible. Or at least that's my guess.
--
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
13 matches
Mail list logo
