Re: [go-nuts] Generic function aliases

This was considered (or rather, the `func g = f` syntax), but ultimately it was decided that the current ways to forward functions are good enough :) Either use var, or if you are uncomfortable with having that *theoretically* mutable, wrap it directly (it should get inlined, so there's no cost

Re: [go-nuts] Generic function aliases

You can use var Gi = g.G(int) or you can use func Gi(i int) error { return g.G(i) } for the same effect. Which is pretty much the reason why alias-declarations ended up only be added for types - all other declarations can already be emulated sufficiently well. :) On Mon, Dec 3, 2018 at 11:39 PM

Re: [go-nuts] Rethink possibility to make circular imports

Anecdote: A (large) Java project I worked on ran into trouble with cyclic dependencies so often, that they started introducing conventions like "classes under directory X are not allowed to import classes under directory Y (but vice-versa)", effectively emulating Go's prohibition of cyclic imports

Re: [go-nuts] Re: is it possible to speed up type assertion?

I'd suggest simply func (b *Binlog) writeArgumentToOutput(writer writer, arg uint64) error { /* do the writing */ } and doing the actual conversions at the call-site. It's type-safe, shorter, faster and more idiomatic - with the tiny downside of a `uint64()` here and there. Alternatively, use

Re: [go-nuts] recommend that error and panic auto coverting

You're right, there is none. IMHO, making recovering from panics easier should be a none-goal. Panics should be reserved for irrecoverable violations of invariants (i.e. bugs) and not recovered, in the general case. The main reason panic/recover is useful today is that it allows to elide some

Re: [go-nuts] recommend that error and panic auto coverting

This seems very similar (almost identical, safe for the choice of words maybe) to the Go 2 error handling draft design . On Thu, Nov 22, 2018 at 11:32 AM Michel Levieux wrote: > I do like the idea, but

Re: [go-nuts] Where is the very first g/m/p?

Using objdump, the actual program start is _rt0_amd64_linux (on that platform, obviously), which, if you follow it, pretty much does nothing but call runtime•rt0_go

Re: [go-nuts] Re: Force pointer at compile time to interface{} parameter

On Mon, Nov 19, 2018 at 10:37 PM Robert Engels wrote: > That is not really true though, as I can declare a method that take a pointer > receiver and mutate through it, but the caller can pass a struct which it > thinks can not be mutated. > > https://play.golang.org/p/Abf4VX9kUTR This is

Re: [go-nuts] Re: Force pointer at compile time to interface{} parameter

The restriction has nothing to do with heaps (in fact, the Go language (i.e. the spec) doesn't even have a concept of a "heap"). It's a type-safety requirement. If you pass in a value, it can't be mutated, full-stop. Reflect shouldn't allow you to bypass type-safety - only "unsafe" can do that,

Re: [go-nuts] How to get the user's umask without race condition?

(and, of course, O_CREATE and everything. sorry for sending multiple messages ^^) On Tue, Nov 6, 2018 at 4:43 PM Axel Wagner wrote: > Oh, come to think of it, there's a way: Use os.OpenFile with mode=0777 and > then stat the file? Should work, no? > > On Tue, Nov 6, 2018 at 4:41 PM Axel Wagner

Re: [go-nuts] How to get the user's umask without race condition?

Oh, come to think of it, there's a way: Use os.OpenFile with mode=0777 and then stat the file? Should work, no? On Tue, Nov 6, 2018 at 4:41 PM Axel Wagner wrote: > That seems to be fundamentally impossible on posix using only syscalls, > but you may be able to use /proc: >

Re: [go-nuts] How to get the user's umask without race condition?

That seems to be fundamentally impossible on posix using only syscalls, but you may be able to use /proc: https://manpages.debian.org/stretch/manpages-dev/umask.2.en.html#NOTES On Tue, Nov 6, 2018 at 4:35 PM Tom Payne wrote: > Hi, > > The user's umask can be set with the umask(2) system call,

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

> > Even though all we did was save some references to values, the code has > radically changed (along with its runtime implications). > Because I am lazy and simply trying to illustrate how this can be done. I was trying to achieve consensus, not to implement generics and I never pretended that

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

On Sun, Nov 4, 2018 at 10:14 PM roger peppe wrote: > Perhaps you might want to have a go at trying to translate a slightly more > substantial piece of generic code. For example, this generic implementation > of Dijkstra's algorithm: https://play.golang.org/p/BsktFSFVU0D. I'd be > interested to

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

On Sun, Nov 4, 2018 at 10:14 PM roger peppe wrote: > This code, for example: https://play.golang.org/p/eaLHBbUJT-d > What might your generated code look like for that? > A bit ad-hoc, but WAI: https://play.golang.org/p/vuCHY2RRxIR In practice, of course, most of these wouldn't be actually

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

On Sun, Nov 4, 2018 at 11:45 AM roger peppe wrote: > One thing to consider: at any point in your program, someone might call > something like the following function with any value in scope: > >var vals []interface{} >func save(x interface{}) { >vals = append (vals, x) >} > >

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

Sorry, should've added what I consider the source: https://play.golang.org/p/3_um7p3IxwK On Thu, Oct 25, 2018 at 10:09 AM Axel Wagner wrote: > Sure: https://play.golang.org/p/W_ruqI22Vhv > Seems a fairly straight-forward transformation to me - and again easy to > devirtualize. > > On Thu, Oct

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

Sure: https://play.golang.org/p/W_ruqI22Vhv Seems a fairly straight-forward transformation to me - and again easy to devirtualize. On Thu, Oct 25, 2018 at 8:56 AM roger peppe wrote: > > On Thu, 25 Oct 2018, 12:52 am Axel Wagner, > wrote: > >> On Thu, Oct 25, 2018 at 12:39 AM roger peppe

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

On Thu, Oct 25, 2018 at 12:39 AM roger peppe wrote: > I understand this argument. By putting some smarts into the compiler, we > would hope that we can see benefits not just in our generated generic code, > but also in other code that we've already written that uses generics. This > would be

Re: [go-nuts] Failed iterator proposals?

On Wed, Oct 24, 2018 at 2:35 PM Eric S. Raymond wrote: > Axel Wagner : > > The key term was "occasionally". I don't know how often "iterators that > > don't need any error handling or cleanup" comes up, but I'd imagine it to > > be pretty rare. In Python, for example, this might be a bit

Re: [go-nuts] Failed iterator proposals?

On Mon, Oct 22, 2018 at 10:41 PM Eric S. Raymond wrote: > Axel Wagner : > > But personally I don't see the point of introducing a custom iterator > concept > > just to *occasionally* save one or two lines of code. > > Don't despise saving lines of code. There's a well-known law the name of >

Re: [go-nuts] Failed iterator proposals?

There's also the additional objection that this doesn't play well with break/return - if the iterator needs to do some cleanup (say, closing a file or something). IMO, these days, just use bufio.Scanner-like iterators or just a channel+context, if syntax is that important to you. But personally I

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

Last addition: On Sun, Oct 21, 2018 at 2:03 PM roger peppe wrote: > Ah, I *think* I see where you might be coming from now. You're thinking > that the compiler could do some kind of Go-to-Go transformation for generic > functions so that they looked exactly as if they'd been written using >

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

On Sun, Oct 21, 2018 at 2:03 PM roger peppe wrote: > Yes. The draft proposal says "generic functions, rather than generic > types, can probably be compiled using an interface-based approach. That > will optimize compile time, in that the package is only compiled once, but > there will be some

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

Thank, I feel I can work with this :) On Sat, Oct 20, 2018 at 10:58 AM roger peppe wrote: > That transformation might be valid for the simple case you have there, > where there's a single parameter of exactly the interface type, but generic > functions allow much more than that. You can have

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

As I said, I don't really understand why we disagree here - or what we are even disagreeing about. So let me make my claim as precise as possible, in the hope that it at least helps me understand which particular part you are disagreeing with. I claim: a) w.l.o.g. we can ignore operators

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

On Thu, Oct 18, 2018 at 2:06 PM roger peppe wrote: > For generics, that analysis is trivial - there is no need to do any > control flow analysis to determine the set of possible generic type > parameters to a type or function (with the exception of recursive generic > functions, which can be

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

On Thu, Oct 18, 2018 at 9:16 AM roger peppe wrote: > The difference is that for generics, you *always* know the exact set of > possible types that a type parameter can be. > If and only if you choose to do that analysis. AFAIK it is not currently planned to do that

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

This is only tangentially related to your specific idea, but I've decided that for generics discussions this is the hill I'm dying on: On Wed, Oct 17, 2018 at 6:44 PM roger peppe wrote: > The method calls in question can be inlined because everything is known > statically, so there's

Re: [go-nuts] why does go reverse the order of name and type? "i int" vs "int i"

There is a full blog article with the answer to this question :) https://blog.golang.org/gos-declaration-syntax It's so good, that I actually use it as a reference to people asking me about C's declaration syntax. On Thu, Sep 20, 2018 at 8:03 AM Tristan Colgate wrote: > But every aspect of that

Re: [go-nuts] Re: Scrapping contracts (was: "Generics as bultin typeclasses")

On Wed, Sep 12, 2018 at 3:55 PM Tristan Colgate wrote: > I'll leave the grown up to discuss after this I promise) > Don't worry. I'm not grown up by any measure. > I guess if I were going to critique this I would say that optimising for > ease of compiler implementation may not be the best

Re: [go-nuts] Generics - Min challenge

ISTM that your requirements can't work. 2) and 3) imply that the expression `x < y` with x,y of type T has to appear at least once in the function body, which means it can never work for a type that doesn't have it. I don't think that has anything to do with changing the type-checking rules

Re: [go-nuts] Re: [golang-dev] go doesn't need generics, but if they do...

On Tue, Sep 11, 2018 at 5:28 PM robert engels wrote: > This seems to contradict this a bit, > https://stackoverflow.com/questions/41586501/why-is-kubernetes-source-code-an-order-of-magnitude-larger-than-other-container > but > it may be an indictment that Go’s lack of

Re: [go-nuts] Re: Generics as builtin typeclasses

On Tue, Sep 11, 2018 at 4:39 PM Larry Clapp wrote: > Directly accessing a field in a generic struct might be *rare*, but it > seems like it shouldn't be *impossible*. > I think it would be better if it is, but if it introduces additional cost, that cost needs to be weighed against the benefit

[go-nuts] Re: [golang-dev] go doesn't need generics, but if they do...

[golang-nuts to CC, golang-dev to BCC] On Mon, Sep 10, 2018 at 5:33 PM robert engels wrote: > In the entire codebase of Docker I could find only one obvious use of > interface{}, and no type casts. > Generics are not only useful for functions taking interface{}. They are also useful for

Re: [go-nuts] Re: Generic types - functions and methods on instantions

On Tue, Sep 11, 2018 at 12:51 PM alanfo wrote: > Whilst you're correct that parameterized types can have methods, I don't > see any reason why instantiated types can't have methods as well, just like > any 'normal' concrete type. > It could, if you're willing to go down the rabbit-hole of

Re: [go-nuts] Re: Generics as builtin typeclasses

Hi Larry, On Tue, Sep 11, 2018 at 3:25 PM Larry Clapp wrote: > This question frankly struck me odd, given the context. To paraphrase: > "Do I have examples of where accessing a field in a generic struct type > might be useful?" I kind of assumed that, hip-deep as we are in a > discussion of

Re: [go-nuts] Re: Scrapping contracts (was: "Generics as bultin typeclasses")

On Tue, Sep 11, 2018 at 1:54 PM Tristan Colgate wrote: > It feels like, so far, all of the attempts to simplify the original design > wind up looking more complicated for little benefit (and reduced > functionality). > There is no accounting for taste, of course, but I wildly disagree. In

Re: [go-nuts] Re: Generic types - functions and methods on instantions

On Tue, Sep 11, 2018 at 11:52 AM wrote: > I'm not sure whether this: > >type Foo(type T) struct{} > > would be allowed or not - the compiler might say "type parameter T is not > used". > > Anyway, if it were allowed, then it would follow that these should also be > allowed: > >func f(x

[go-nuts] Scrapping contracts (was: "Generics as bultin typeclasses")

I don't know if fragmenting the conversation will improve or decrease clarify. I also agree that we should primarily focus on the existing generics design by Ian and Robert. So if you find this kind of conversation counter-productive, please ignore :) That being said, I also feel I'll understand

Re: [go-nuts] Re: Generics as builtin typeclasses

The unambiguous cases aren't ambiguous of course. It's the ambiguous cases I'm concerned about :) My post and this thread contain a bunch of those. They are mostly growing out of builtin functions and things like `range` statements and index-expressions. You can translate all of my

Re: [go-nuts] Re: Generics as builtin typeclasses

Don't worry, I still got the point :) And already yielded that treating pseudo-interfaces as types won't work and that it requires some polish on phrasing :) On Tue, Sep 11, 2018 at 1:16 AM Jonathan Amsterdam wrote: > I'm wrong about `==` here, because it's defined for interface values. >

Re: [go-nuts] Re: Generics as builtin typeclasses

On Mon, Sep 10, 2018 at 8:57 PM Jonathan Amsterdam wrote: > FWIW, I think Ian's criticism of not wanting a list of new identifiers to >> express operator constraints is fair. It is a genuine roadblock to c) and >> if we're dead set of setting that as a baseline requirement, I agree that a >>

Re: [go-nuts] Re: Generics as builtin typeclasses

On Mon, Sep 10, 2018 at 2:03 PM Jonathan Amsterdam wrote: > You and many others have tried to replace contracts with interfaces. > Almost, but not quite. I and others have tried to replace contracts with *something*. Preferably something declarative. ISMT interfaces fit the bill *pretty well*.

Re: [go-nuts] Re: Generics as builtin typeclasses

On Mon, Sep 10, 2018 at 12:47 AM Randall O'Reilly wrote: > WRT the objection of introducing a bunch of new keywords to explicitly > specify what is otherwise indirectly specified by contracts, there is > already a full explicit list of such things in the reflect.Kind type. > Could we not just

Re: [go-nuts] Re: Generics as builtin typeclasses

I don't think saying that is is productive. contracts are more than just "identifiers used as constraints", they are also a syntactic construct to specify those. I specifically don't allow that and that's the whole point I'm making. So this doesn't seem like a particularly nice way to have a

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sun, Sep 9, 2018 at 11:08 PM Jonathan Amsterdam wrote: > func ShortestPath(type G Graph(Node, Edge), Node, Edge) (g G, from, to >> Node) []Edge >> > > I don't think this syntax is valid according to the draft design, or your > blog post. Node and Edge are used before they are declared. > I

Re: [go-nuts] Re: Generics as builtin typeclasses

018 at 12:18 PM, 'Axel Wagner' via golang-nuts > wrote: > > > > I disagree with the premise that we need operators for generics - when I > > think of "generics", I usually think of "type-safe, constrained, > parametric > > polymorphism"

Re: [go-nuts] Re: Generics as builtin typeclasses

Oh, I actually wanted to add something about this: Whether or not this will *actually* end up being static or dynamic dispatch is, AIUI, intentionally left open in the proposal. The current thinking, AIUI, is

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sun, Sep 9, 2018 at 8:49 PM Jonathan Amsterdam wrote: > The problem is that this program seems to type-check, but it is invalid. > The == operator is specified to work on operands of the same type, and it > is being used on operands of different types. > Good point. I have to think about it.

Re: [go-nuts] Re: Generics as builtin typeclasses

True. You can get static dispatch by func ShortestPath(type G Graph(Node, Edge), Node, Edge) (g G, from, to Node) []Edge On Sun, Sep 9, 2018 at 8:21 PM Jonathan Amsterdam wrote: > >> FWIW, in my pseudo-interface description >> , >> >

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sun, Sep 9, 2018 at 9:35 AM Ian Lance Taylor wrote: > As I've said before, I would very much like to avoid adding many > different names to the language. Also, there are many different cases > to handle. Consider type conversions, for example; how do you express > that you want to have two

Re: [go-nuts] Re: Generics as builtin typeclasses

On Fri, Sep 7, 2018 at 3:10 PM Ian Lance Taylor wrote: > This does surprise me. I'm certainly too close to the problem, but to > me it always seems quite clear which type arguments a contract allows > and excludes. It's exactly the set of types that type check successfully. I yield that it's

Re: [go-nuts] Re: Generics as builtin typeclasses

On Fri, Sep 7, 2018 at 2:00 AM xingtao zhao wrote: > Try to raise my point here (from another thread): > > I think all of the operator constraints should be retrieved implicitly. > The proposal of the contract on operators seems a design flaw to me: why do > we express that if < is in the

Re: [go-nuts] Why can't we use unicode? [Go2 Generics]

And while we're at it, why "func", instead of the far simpler λ, or "type" instead of τ, or "include", instead of ι, "const" instead of κ and "war" instead of ω. We can do ρ instead of "range", φ instead of "for", ν is "new" and μ is "make", obviously. And while we're at it, let's also use ≥ and ≤

Re: [go-nuts] Re: Generics as builtin typeclasses

On Fri, Sep 7, 2018 at 12:37 AM Ian Lance Taylor wrote: > On Thu, Sep 6, 2018 at 3:04 PM, Axel Wagner > wrote: > Interesting point. But is there any way to solve it short of > explicitly listing types? Is there any generics system in any > language that avoids this problem? > I'm not saying

Re: [go-nuts] Re: Generics as builtin typeclasses

My point was that type-classes don't really help in and off itself. What helps is that operators are methods (i.e. Haskell has operator overloading). If Go had operator methods, that would work too (obviously), because you could write an interface for them. Anyway :) On Fri, Sep 7, 2018 at

Re: [go-nuts] Re: Generics as builtin typeclasses

On Thu, Sep 6, 2018 at 11:36 PM jimmy frasche wrote: > To unify those cases you need something like haskell-style typeclasses > where you can say this type satisfies this contract using these > methods/operators. > FWIW, the Go way of doing that is embedding it in a new struct and overwriting

Re: [go-nuts] Re: Generics as builtin typeclasses

Hi Ian, On Thu, Sep 6, 2018 at 9:45 PM Ian Lance Taylor wrote: > On Thu, Sep 6, 2018 at 10:29 AM, jimmy frasche > wrote: > > This is clearly a key issue. I happen to think that contracts are > fairly clear for the reader: take your type argument and see if the > contract body works. I feel

Re: [go-nuts] Re: Generics as builtin typeclasses

FWIW, personally I think type parameters are far more important than contracts about the draft design. i.e. I agree, that if you can't make contracts work (or decide they aren't a good solution), I'd still think it's worth considering to only add type-parameters on their own. To me, contracts

Re: [go-nuts] Re: Generics as builtin typeclasses

Oh and of course I make up my own name too, with "pseudo-interfaces" (to reflect the connection to interfaces in regards to embedding and general usage). On Wed, Sep 5, 2018 at 4:12 AM Axel Wagner wrote: > I swear I didn't know about that feedback when I just wrote this ;) >

Re: [go-nuts] Re: Generics as builtin typeclasses

I swear I didn't know about that feedback when I just wrote this ;) https://blog.merovius.de/2018/09/05/scrapping_contracts.html (i did know about Matt's post and mention it) I hoped to provide a somewhat extensive argument about why I don't really "like" contracts and how interface-based

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

this is potentially avoids the interface call >>> allocation?). >>> This is a good example of my gut feeling about generics, I realise >>> they'll be valuable, but do they devalue interfaces? They do not seem like >>> an orthogonal feature. Of the two, interfa

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

A contract can include multiple type parameters: https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#mutually-referential-type-parameters AIUI your syntax can't cover that. And FWIW, I find the syntax of contracts in the doc far less "magic" than yours, but YMMV of course.

Re: [go-nuts] Re: function's argument default value

On Thu, Aug 23, 2018 at 9:44 AM Masoud Ghorbani wrote: > Your opinion is like to say all of the python application should rethink > and re-write their structure because they used default values. > One general thing to observe in all these discussions is, that Go is not Python (or Rust, Haskell,

Re: [go-nuts] Re: Garbage collector and Slices

I'm not 100% sure, but… pretty sure? that the GC does not look at the len/cap fields of slices. Reason being that that would require significant alias-analysis, as two slices of the same underlying array can have different lengths and capacities. So treating the underlying array not as "one

Re: [go-nuts] Re: Ternary ... again

luation of the values with respect to the condition, I suspect that > an if statement would be more appropriate anyway. > > On 16 August 2018 at 09:11, 'Axel Wagner' via golang-nuts > wrote: > > Hi Sam. A couple small responses inline. > > > > On Thu, Aug 16, 2018 at

Re: [go-nuts] Re: Ternary ... again

read if it does *not* > contain re-assignments and branches, and temporary variables used only > once. With a ternary operator, you can code like that for cases where it > makes sense. I would much rather write: > > return FooBar{ > Field: someCond ? blah : bar, > } &

Re: [go-nuts] Ternary ... again

Hi, On Wed, Aug 15, 2018 at 1:23 PM Mark Volkmann wrote: > I understand that many requests for syntax additions are rejected on two > grounds. Really though, the reaction always happens on the same grounds: It is not shown that the benefit outweighs the cost. You mention the cost in your

Re: [go-nuts] Re: Go modules and semver question

True. That depends a lot on what package we are talking about. You can check whether that is the case for the specific package in question. Have a look at the "Avoiding Singleton Problems" section of Russ' article. IMO it is the responsibility of the package author to make sure, that different

Re: [go-nuts] Go modules and semver question

Neither API nor Behavior of your module has changed, so it's definitionally a patch release. Go modules have an explicit design goal to enable using multiple major versions of a module in the same binary. i.e. your situation is basically what's described here as a motivation for semantic import

Re: [go-nuts] Re: Ternary ... again

In my opinion Python serves as a poor argument here. I tend to use Python as a example of a grab-bag language that adds any feature anyone considers useful - without considering the cost. An Anti-Go, if you will :) Gustavo Niemeyer actually wrote this up pretty well:

Re: [go-nuts] Ternary ... again

There is lots of discussion findable here: https://groups.google.com/forum/#!searchin/golang-nuts/ternary%7Csort:date There's a bit of discussion on the issue tracker: https://github.com/golang/go/issues?utf8=%E2%9C%93=ternary+operator -- in particular https://github.com/golang/go/issues/23248

Re: [go-nuts] Re: Nil Channels and Case Evaluation

FWIW, either way the error message is not related to order of evaluation or anything. It always happens with nil-channels: https://play.golang.org/p/aBga7KFN30x On Wed, Aug 8, 2018 at 5:46 PM Sam Whited wrote: > > > On Wed, Aug 8, 2018, at 04:40, Jan Mercl wrote: > > On Wed, Aug 8, 2018 at

Re: [go-nuts] Why does Go not include a stack trace by default in the errors package?

The message from an `error` is not for consumption by a developer, trying to find a bug in their program, but for consumption by a user/operator, trying to find out what caused a failure. They may seem similar use-cases, but in general, the latter finds stack traces incredibly useless and

Re: [go-nuts] Re: Go could really use a while statement

On Thu, May 3, 2018 at 3:46 PM wrote: > And for those who compare if and switch arguing it is equivalent, you > can't do type switches with an if statement. > Yes, you can if r, ok := r.(*bytes.Buffer); ok { // Use r as a *bytes.Buffer } else if r, ok :=

Re: [go-nuts] Go could really use a while statement

On Wed, May 2, 2018 at 11:48 AM Hugh Fisher wrote: > As for not adding any power, that's why I mentioned if-then-else and > switch. > Switch with boolean cases is the same as if then else. It's not an obscure > side effect either, the Go Tour cheerfully explains how to use

Re: [go-nuts] proposal: disallow implicitly comparing true with value of interface{} in a switch with no value

On Sat, Apr 21, 2018 at 3:30 PM wrote: > Why is this special? Because it's commonly used. Is it? I don't think I ever used an interface value in a switch. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from

Re: [go-nuts] On Accepting Interfaces and Structs

On Sat, Apr 21, 2018 at 1:52 PM Kaveh Shahbazian wrote: > Is there a way to actually achieve this? > Either change `second.cloner` to return an interface, or (IMO better) just import `second`. I don't understand why you'd want to avoid that. -- You received this

Re: [go-nuts] proposal: advise using SetFinalizer to detect resource leaks

Of course this happens when you don't test your code ^^ Here is a version without compilation errors and with a quick demo: https://play.golang.org/p/ykO4igrC0b1 On Thu, Apr 5, 2018 at 2:06 PM, Axel Wagner wrote: > On Thu, Apr 5, 2018 at 1:58 PM, Mateusz

Re: [go-nuts] proposal: advise using SetFinalizer to detect resource leaks

On Thu, Apr 5, 2018 at 1:58 PM, Mateusz Czaplinski wrote: > Reading from it and handling the errors is left to user. > Then why would this need to live in the stdlib? For example here is a quick and dirty implementation that allows the same functionality, without having to

Re: [go-nuts] proposal: advise using SetFinalizer to detect resource leaks

What would the runtime.Leaks channel do with the received errors? Why can't you just do the same thing from the finalizer itself? On Thu, Apr 5, 2018 at 1:43 PM, Mateusz Czapliński wrote: > Based on a recent discussion on reddit, and a reply by BowsersaurusRex: > > "In

Re: [go-nuts] Re: using gofmt "internally" to format a string, aka in memory go code formatter

or just https://godoc.org/go/format On Mon, Mar 26, 2018 at 7:48 PM, Elias Naur wrote: > The gofmt command by default reads from standard input and outputs to > standard output. It doesn't need a temporary file. > > Alternatively, use the go/ast package to parse Go source

Re: [go-nuts] an "append" use, bug or intended design?

On Fri, Mar 16, 2018 at 8:20 PM, T L wrote: > > > On Friday, March 16, 2018 at 2:57:48 PM UTC-4, Jan Mercl wrote: >> >> On Fri, Mar 16, 2018 at 7:40 PM T L wrote: >> >> >> > I feel the second append call should be also valid. >> >> Works as intended: T is

Re: [go-nuts] Why should i use interface composistion

The advice regarding small interfaces goes further than just a simple "don't put many methods in an interface" - it includes (and is based on) a different philosophy of using interfaces. The advice assumes that you shouldn create an interfaces for the database backend in the first place - instead,

Re: [go-nuts] What major API change really is?

Yes, definitely. The only way that *wouldn't* break a reverse dependencies code is if they'd only use the function with number-literals. Which is sufficiently unusual to be put very firmly on the "breaking change" side of things. FWIW, I've written

Re: [go-nuts] copy is not very essential function? It can always be simulated by append?

There is another significant difference between append and copy, which is that copy only copies the minimum number of elements in either slice. So, if you want to simulate copy via append, you'd need to at least throw a couple of if's in there. Of course,

Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

Can you elaborate/link to example code? Because it seems to work just fine . On Wed, Feb 28, 2018 at 6:58 PM Kaveh Shahbazian wrote: > BTW I have found an interesting usage for embedding type aliases. Assume a > type A embeds

Re: [go-nuts] Appreciating Go

On Sat, Feb 24, 2018 at 11:04 PM Bakul Shah wrote: > r := os.Open(filename) > if isError(r) { return r.(error) } > f := r.(*os.File) // or better: var f *os.File; f = r > This still does not seem meaningfully different to me, though. * You are writing isError(r), instead of

Re: [go-nuts] New to Go; Saying Hello !

o/ We're happy to have you :) On Fri, Feb 23, 2018 at 6:11 PM Daniel Skinner wrote: > hi :) > > On Fri, Feb 23, 2018, 8:26 AM wrote: > >> So, I started programming in Go about a month ago. I can't stop. >> I can't even describe why I am enjoying the

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

On Thu, Feb 22, 2018 at 10:27 PM wrote: > On Thursday, February 22, 2018 at 9:53:20 PM UTC+8, Axel Wagner wrote: >> >> Daisy chaining would mean I would only have to code API translations for >>> the latest API but then it's debug hell and if one version in the chain >>>

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

On Thu, Feb 22, 2018, 12:43 wrote: > On Thursday, February 22, 2018 at 5:29:23 PM UTC+8, Axel Wagner wrote: >> >> Have you read https://research.swtch.com/vgo-import? It talks about >> singletons and also how to solve that with different import paths. >> Note, that this is

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

On Thu, Feb 22, 2018 at 7:18 AM wrote: > I don't think changing the module name would be a good idea for singletons > tho. > Have you read https://research.swtch.com/vgo-import? It talks about singletons and also how to solve that with different import paths. Note, that

Re: [go-nuts] Re: Go += Package Versioning

On Thu, Feb 22, 2018 at 9:50 AM dc0d wrote: > And the first idea is about having packages that does not harm the > environment (like by importing reflect or executing external commands), and > seems to be a feasible goal. > Apologies, I was ambiguous in my quote, I

Re: [go-nuts] Re: Go += Package Versioning

On Thu, Feb 22, 2018 at 7:10 AM dc0d wrote: > I'm looking forward to see this in official releases too! > > Also I would like to: > > - Have a mechanism for safe dependency packages (as in Safe-Tcl > - this implies it would

Re: [go-nuts] Go += Package Versioning

On Thu, Feb 22, 2018 at 4:21 AM David Anderson wrote: > Currently, per the vgo tour, the entire transitive closure gets updated, > which, per the article's definition, results in a low-fidelity build... If > you assume that the intent of `vgo get -u` was "the libraries I'm

Re: [go-nuts] Go += Package Versioning

On Wed, Feb 21, 2018 at 11:55 PM David Anderson wrote: > Reading the latest post, https://research.swtch.com/vgo-mvs , a > question... > > It feels to me like there's a missing 5th operation, in additions to the > one you proposed: "upgrade all my *direct* dependencies to their

Re: [go-nuts] Go += Package Versioning

On Wed, Feb 21, 2018 at 10:17 PM Peter Bourgon wrote: > ·Any· change to the exported API of a package except adding new > top-level identifiers can be considered an incompatible (breaking) > change. > > https://blog.merovius.de/2015/07/29/backwards-compatibility-in-go.html I

Re: [go-nuts] Experience report with nil interface{}

Personally, I'd argue that you are misattributing the root cause. The code you posted at least, does not check the error of ensureOpen. If it would have, then it wouldn't have crashed. It is pretty common in Go, to return a valid value if and only if no error is returned alongside it. It is also

Re: [go-nuts] Re: ioutil.ReadAll()

Why are the things mentioned so far not sufficient? ReadAll returns a non-nil error, if the reader you are passing to it returns a non-nil, non-EOF error. In this case, you are passing Response.Body , which does not make any guarantees regarding the errors

<    5   6   7   8   9   10   11   12   13   >