Re: [go-nuts] where in gc compiler does converting from syntax.TypeDecl to reflect.Type happen?

I can give you a little bit of a start: I looked at the runtime recently, and its representation is here . It doesn't tell you how the creation/translation happens, but it tells you how the low-level

Re: [go-nuts] Guarantees about evaluation order but not slice indexing

On Tue, Jan 30, 2018 at 9:10 AM, Dmitriy Cherchenko wrote: > It looks like the language spec is a little imprecise in the Order of > evaluation section > about if any function evaluating an index of a slice will always be invoked > before anything

Re: [go-nuts] Guarantees about evaluation order but not slice indexing

On Tue, Jan 30, 2018 at 7:20 PM, Dmitriy Cherchenko wrote: > The second possibility you described is exactly what I’m worried about. > But I have several places where I’m doing something like b.data[b.grow()] = > bt and wouldn’t want to break that up into two lines everywhere. I was > wondering i

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

On Wed, Jan 31, 2018 at 12:19 AM, wrote: > - When slices can be compared, they can be used as map keys. What happens >> if the contents of a slice are changed after it has been added to a map? > > > I’m not too familiar with Go map internals, but my thought is the key hash > would depend on the b

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

> What about a proposal addition of “types with self-references in slices cannot be compared”? Are you sure that's the only edge-case? Because this thread is kinda long and there might even be things we are not thinking about. > I’m curious about examples where people wanted one or the other. I o

Re: [go-nuts] GOTCHA: Just when you think you understand interfaces

You have to use reflection for that. Go doesn't have subtyping of that kind. This smells a bit of an xy-problem to me, though. There are several things here, that suggest an antipattern going on. With a little bit of context on the actual problem you are trying to solve, we

Re: [go-nuts] GOTCHA: Just when you think you understand interfaces

FTR, you can also pass an actual []Usable, instead of a []tmpType. That is do https://play.golang.org/p/N_CJh0Ekik8 But I do think that your code and question suggest that you are trying to use interfaces to do some sort of subtyping, which is just not how they are supposed to be used. On Wed, Jan

Re: [go-nuts] GOTCHA: Just when you think you understand interfaces

It seems that https://godoc.org/sort#Interface is the way to go here. You can combine it with reflect.Swapper to get an API like https://godoc.org/sort#Slice On Wed, Jan 31, 2018 at 6:52 PM, Chris Hopkins wrote: > Okay well the actual (working version) of the code (before I wrote the > test case

Re: [go-nuts] Re: GOTCHA: Just when you think you understand interfaces

On Thu, Feb 1, 2018 at 11:52 AM, Chris Hopkins wrote: > Yeah, so having played with this. It seems that this is going to take some > judicious use of reflect if I'm to stand any chance of maintaining a > flexible API, which I really hoped to avoid. > I'm 99% sure that you don't have to use refle

Re: [go-nuts] Re: GOTCHA: Just when you think you understand interfaces

I don't really see the difference in writing func Less(a, b *T) bool and func (a *T) Less(b *T) bool convenience wise - except that the latter requires the name to be exported and doesn't allow using a function literal (so, yeah, the latter actually seems significantly *less* convenient). On Thu,

Re: [go-nuts] Why is the omitted expression in a swtich code block a typed bool "true"?

>From the spec: > If the switch expression evaluates to an untyped constant, it is first > converted to its default type; if it is an untyped boolean value, it is > first converted to type bool. The predeclared untyped value nil cannot be > used as a switch expression. The current behavior is s

Re: [go-nuts] Why is the omitted expression in a swtich code block a typed bool "true"?

I did end up asking git, why this was done and it gave this answer , which links to this discussion . Hope that helps On Fri, Feb 2, 2018 at 5:18 PM, wrote: > > > On Friday, F

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

On Fri, Feb 2, 2018 at 9:59 PM, wrote: > > Each path represented as a slice of coordinates could be easily encoded to > a string and compared that way. > Ah, I misunderstood "path". > > As far as resource expenses go, we'd need benchmarks to say much. I > understand looking at expensive cases t

Re: [go-nuts] how can I convert from monotonic clock to wall clock?

The best way is to use time.Format with a format of your choosing; if you need to control the way a time is printed, actually control it :) That being said, the documentation of the time package says The canonical way to strip a monotonic clock reading is to use t = > t.Round(0). i.e. https://p

Re: [go-nuts] Re: GOTCHA: Just when you think you understand interfaces

On Mon, Feb 5, 2018 at 1:13 PM, Chris Hopkins wrote: > Well, the first allows one Less per package, the second allows one per > type. > No, the first allows an arbitrary number of Less' per package or type and the second one allows one per type. You can call a function LessByName, LessByID, Less

Re: [go-nuts] Question about the spec: Method Sets and Pointer Receivers

That sentence wouldn't be true, though. There is a call-expression shorthand, but the method does not actually get added to T - so, for example var b bytes.Buffer b.WriteString("foo") // fine (&b).WriteString("foo") // the same, as it's just syntactic sugare r := strings.NewReader("foo") io.Copy(b

Re: [go-nuts] Re: Why is there no standard `uuid` package?

On Fri, Feb 9, 2018 at 6:24 AM, Henry wrote: > I don't think UUID representation (whether with dash or without dash or > how many dashes) is a strong argument for not including UUID into Go's > stdlib. > Then how about the bigger problem: Semantics. There are tradeoffs of throughput, latency, co

Re: [go-nuts] type definitions and original types

On Sun, Feb 11, 2018 at 7:27 AM, rajesh nataraja wrote: > Compiler does not allow this, aren't they essentially all the same? What > is the reason this is not allowed? > Go is strictly typed. As such, it limits conversions (much more automatic ones) between types that are not the same. Types are

Re: [go-nuts] type definitions and original types

On Sun, Feb 11, 2018 at 4:52 PM, rajesh nataraja wrote: > Yes I understand the strict type checking. But in the absence of macros, > the code becomes extremely awkward and sometimes the simplicity that we > beg for gets undermined. > My intention trying to do this was two things: > 1. Reduce my

Re: [go-nuts] Safe Packages

What does "safe" mean, in this context? In any way, I don't think you can determine that in general. Go allows race conditions and in general they might be abused to do arbitrary unsafe operations, AIUI. If you want safe execution of Go code, use nacl. On Mon, Feb 12, 2018 at 8:43 PM, dc0d wrote

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

For example: https://play.golang.org/p/ycoR-jU48J9 The only read error it ignores is io.EOF (which makes complete sense, when you think about it), everything else get passed up. On Tue, Feb 13, 2018 at 9:19 AM, Patrik Iselind wrote: > Hi, > > I have a hard time imagining when https://golang.or

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

Not very, but it does depend on the details. For example, you might provide your own http.Transport for the client to use, or even your own net.Conn. You might have the server stop sending any data, so eventually the connection will timeout. The question is, though, why would you want that? Is tha

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

On Wed, Feb 14, 2018 at 10:01 AM mrx wrote: > > On Tue, Feb 13, 2018 at 5:26 PM, Axel Wagner < > axel.wagner...@googlemail.com> wrote: > >> Not very, but it does depend on the details. For example, you might >> provide your own http.Transport for the client to use, or even your own >> net.Conn. >

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

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 no

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 should probably go

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 latest > version,

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 calling > have new feat

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 be > possible to have meta-d

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 wasn't trying to say anything

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 this is also independent

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 also independent of *ho

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 >>> breaks, >>> it means fixi

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 language so much, except by >> saying... >

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 err != nil * You are

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 another type B that has a memb

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, the

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] 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] 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 not struct{} >> >> If desired, it can be

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 and go/printer to > pre

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 C# I'll often use fina

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 modify the stdlib: htt

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 Czaplinski > wrote: > >> Reading from it

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 message because you are subscri

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 this group and stop r

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 it instead > of > if-th

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 := r.(*os.File); ok { // Use r as a

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 frustrati

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 11:15

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&q=ternary+operator -- in particular https://github.com/golang/go/issues/23248 Th

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: https://blog.labix.org/2012/06/

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 ver

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 maj

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 mess

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

eld = blah > } else { > foo.Field = bar > } > return foo > > In my experience code is clearer and easier to 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 cas

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, 20

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 object"

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

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

declaring the function takes a Stringer? Am I >>> missing something (presumably 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

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

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. It seems pretty obvious to me, that if you instantiate my MultiReader example to, say, *strings.Reader, it would fail to compile. Because *multiReader is not a *string

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 type-par

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 ;) > https://blog.meroviu

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 o

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 th

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 th

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 12:21

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 t

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

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 a

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 t

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

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 t

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

ep 9, 2018 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 > > pol

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 h

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 discus

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 use

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

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

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

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 "pseudo-interfa

[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 th

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 Fo

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 partic

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 ge

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 overlo

[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 functio

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 :)

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 classes/inheritance/generic

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 though

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 thi

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] 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 theoretical

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

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 disa

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 (includin

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 typ

  1   2   3   4   5   6   7   8   9   10   >