Re: [go-nuts] Why is type inference still so rudimentary?

[jimmy frasche]

I wish there were more cases where the types could be elided. Always
leaving it off would be a bad idea but how much to put in should be at
the author's discretion. There are times when it clarifies but more
times when it just adds extra steps. I know that the current rules
have justifications but they still feel entirely arbitrary and it's
getting to be one of the more annoying aspects of reading and writing
Go (because most everything else has been addressed!)

On Fri, Aug 4, 2023 at 10:39 AM Ian Lance Taylor  wrote:
>
> On Fri, Aug 4, 2023 at 8:08 AM Nate Finch  wrote:
> >
> > If I have a struct
> >
> > type User struct {
> > Name string
> > ID int
> > }
> >
> > type Group struct {
> >  Leader  User
> > }
> >
> > Why is it that the go tool can't infer what type I'm constructing for the 
> > Leader field here?
> >
> > g := Group{
> > Leader: {
> >Name: "Jamie",
> >ID: 5,
> > },
> > }
> >
> > Cleary, the compiler knows I'm constructing a variable of type Group, and 
> > thus should know that Leader: is a field in Group, and thus what type I am 
> > constructing to assign to that field.  It's not like it's an interface 
> > where I could be assigning anything.
> >
> > Finally, why does this work with maps, but not struct fields?
> >
> > users := map[string]User {
> > "Jamie" : {
> >Name: "Jamie",
> >ID: 5,
> >  },
> > }
> >
> > This works and feels almost identical to the Group code above. Define the 
> > enclosing type, and then the subtype is obvious and thus implicit.
> >
> > I presume this is some parser thing where it can't distinguish between two 
> > possible valid constructions, though I can't think of exactly what other 
> > construction it might mean
>
> I think this is https://go.dev/issue/12854.  At least that is related.
>
> The reason we don't do it today boils down to: we implemented it in
> gofmt -s and weren't really happy with how it looked.  A number of
> existing composite literals became nearly unreadable when the types
> were omitted.  They were just collections of braces and elements, and
> it was hard to tell what they meant.  That was a long time ago and we
> may feel differently now, if somebody wants to seriously investigate.
>
> 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/CAOyqgcVTbE%3DxqDDO64d5ZOXD7VgOcNf0WzZzNP5T_esJ6HTP1Q%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANG3jXLGmtba2AS%3DPaFUnDbbFb-439HYSWD_oQ7ckXhYKt-wsA%40mail.gmail.com.

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

[jimmy frasche]

I don't want a generic min unless it looks like this:

func Min[T constraints.Ordered](a, b T) T {
  switch T {
  case float32:
return T(math.Min(float32(a), float32(b)))
  case float64:
return T(math.Min(float64(a), float64(b)))
  }
  if a < b {
return a
  }
  return b
}

On Fri, Aug 21, 2020 at 3:03 PM Axel Wagner
 wrote:
>
> On Fri, Aug 21, 2020 at 11:46 PM Ian Lance Taylor  wrote:
>>
>> Yes, there are various such possibilities.
>>
>> What jimmy frasche said above is correct: nothing changes in the case
>> of a type switch of a type parameter.  The code now knows the type
>> list element that the type argument matched, but it can't do anything
>> that it couldn't do anyhow.
>
>
> I think there are two reasonable things that it could be allowed to do in the 
> case, that aren't allowed outside:
> 1. Convert to the matched type. We have a guarantee that the matched type is 
> either identical or has the same underlying type, both of which would allow a 
> conversion in the language as-is. I feel allowing this conversion would be 
> sufficiently useful (e.g. passing things to `strconv.Itoa` or functions from 
> `math` can be very useful).
> 2. If the type is not a predeclared type, we could even take this a step 
> further, as the types must be identical - so we might allow treating them as 
> such. This feels natural when viewed from the "type lists are essentially sum 
> types" POV. However, it would treat predeclared types more special than other 
> declared types and so it may be too elaborate to put into the spec. It would 
> also allow what rog suggest - but only in certain corner cases, which feels 
> weird.
>
> The more I think about it, the less I understand the intention behind the 
> type-switch construct introduced. I tend to agree that 1. at least should be 
> possible to make it useful. But even then, it seems like kind of a big change 
> for relatively limited use. What was the motivation behind that change? Is 
> there discussion somewhere, of interesting use-cases this enables?
>
>
>>
>>
>> Ian
>>
>> On Fri, Aug 21, 2020 at 2:43 PM Axel Wagner
>>  wrote:
>> >
>> > also, of course, you could still use operators with them, while now also 
>> > knowing the exact semantics of those operators (e.g. in regards to 
>> > overflow), which might also be useful.
>> >
>> > On Fri, Aug 21, 2020 at 11:42 PM Axel Wagner 
>> >  wrote:
>> >>
>> >>
>> >>
>> >> On Fri, Aug 21, 2020 at 11:30 PM roger peppe  wrote:
>> >>>
>> >>> On Fri, 21 Aug 2020 at 22:10, jimmy frasche  
>> >>> wrote:
>> >>>>
>> >>>> I'd assume that would fail to compile as you're returning a []T not a 
>> >>>> []int
>> >>>
>> >>>
>> >>> If that's the case, then I'm not sure that such a type switch would be 
>> >>> very useful. It would tell you what type the values are, but you can't 
>> >>> do anything with them because all the values would still be of the 
>> >>> original type.
>> >>
>> >>
>> >> You can reasonably convert them to their underlying type and *then* use 
>> >> them as such.
>> >> That would make it useful while not allowing what you posit.
>> >>
>> >>> I had assumed that the intention was that within the arm of the type 
>> >>> switch, the switched type would take on the specified type.
>> >>> That would allow (for example) specialising to use underlying machine 
>> >>> operations on []T when T is a known type such as byte.
>> >>
>> >>
>> >> It would, however, prevent you from calling methods on the type or pass 
>> >> it to a function taking an interface compatible with the constraint.
>> >> Also, I shudder to even imagine how this could be put into a spec.
>> >>
>> >>>
>> >>>
>> >>>
>> >>>> On Fri, Aug 21, 2020 at 2:07 PM roger peppe  wrote:
>> >>>> >
>> >>>> >
>> >>>> > On Fri, 21 Aug 2020 at 01:28, Ian Lance Taylor  
>> >>>> > wrote:
>> >>>> >>
>> >>>> >> After many discussions and reading many comments, we plan to move
>> >>>> >> forward with some changes and clarifications to the generics design
>> >>>> >> draft.
>> >>>> >>
>> >>>> >> 1.
>> >>

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

[jimmy frasche]

I'd assume that would fail to compile as you're returning a []T not a []int

On Fri, Aug 21, 2020 at 2:07 PM roger peppe  wrote:
>
>
> On Fri, 21 Aug 2020 at 01:28, Ian Lance Taylor  wrote:
>>
>> 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
>> parameters.
>>
>> 4.
>>
>> 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)”.  A type switch on a type
>> parameter won’t be able to use the “:=” syntax anyhow, so there is no
>> reason to require “.(type)”.  In a type switch on a type parameter
>> with a type list, every case listed must be a type that appears in the
>> type list (“default” is also permitted, of course).  A case will be
>> chosen if it is the type matched by the type argument, although as
>> discussed above it may not be the exact type argument: it may be the
>> underlying type of the type argument.
>
>
> Here's one interesting implication of this: it allows us to do type 
> conversions that were not previously possible.
>
> For example, if we have "type I int", we can use a type switch to convert 
> some type []I to type []int:
> https://go2goplay.golang.org/p/-860Zlz7-cn
>
> func F[type T intlike](ts []T) []int {
> switch T {
> case int:
> return ts
> }
> return nil
> }
>
> It seems to me that this kind of thing will allow us to perform a similar 
> conversion (convert some part of the type to its underlying type) on any 

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

[jimmy frasche]

To clarify on the type switches, would it have to be used like this:

type C interface {
  type X, Y
}

func f(x X) X {
  return x
}

func g[T C](v T) T {
  switch v {
  case X:
// to use v as an X
// we must convert
x0 := X(v)
x1 := f(x0)
// to use x1 as a T
// we must convert back
t := T(x1)
return t
  case Y:
return v
  }
}

And that the lack of a dedicated syntax to distinguish the case like
.[type] also means that you could no longer write

func h[T comparable](x, a, b T) {
  switch x {
  case a:
  case b:
  }
}

Regardless, all of these changes are fantastic!

On Thu, Aug 20, 2020 at 8:20 PM Robert Engels  wrote:
>
> I like it. Well done.
>
> > On Aug 20, 2020, at 9:22 PM, Jan Mercl <0xj...@gmail.com> wrote:
> >
> > On Fri, Aug 21, 2020 at 2:28 AM Ian Lance Taylor  wrote:
> >
> >> 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{}”.
> >
> > Anyone can write the declaration
> >
> >type any = interface{}
> >
> > today and possibly some people already do that. But in my opinion that
> > would, so far, not pass a code review within the Go project per se.
> > (It would definitely not pass my code review.)
> >
> > I don't like it and It makes me sad it is being proposed to become
> > officially blessed.
> >
> > --
> > 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/CAA40n-XDYjhoMXt%3DEP82EPSrrbmM2D4OsgtEwdx38h7HU5DwWw%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/34314A4C-79B4-4913-9404-26EF1267115F%40ix.netcom.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/CANG3jXL0fv2rptqrP6v5oPuih3HKA8yp12sRt8PJgC7dcSj%2BCA%40mail.gmail.com.

Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

[jimmy frasche]

If I have
  func F[type E interface{}, S constraints.Slice[E]]() S
are the following equivalent:
  F[int, []int]
  F[int]
  F[[]int]
or are only 2 of the 3 permissible? Does that change if I swap the
type parameters?

On Thu, Aug 13, 2020 at 4:31 PM Michael Jones  wrote:
>
> Yes, thank you. In intellectual shame I must say that I somehow understood 
> that the generics needed to be "leaf" functions. Thank you for demonstrating 
> my oversight. Happier now.
>
> Michael
>
> On Thu, Aug 13, 2020 at 3:47 PM Bakul Shah  wrote:
>>
>> On Aug 13, 2020, at 3:29 PM, Michael Jones  wrote:
>> >
>> > The all-or-none aspect would be sidestepped if it were allowed to define 
>> > "partial generics":
>> >
>> > func A (T1, T2) (...){}
>> >
>> > func B(T)(...){ A(T,int)(...){...} }
>> >
>> > Allowing B to exist just means running the whole generic thing iteratively 
>> > until no resolution is changed. If the fixed point still has generic types 
>> > then the compilation is a failure, otherwise, a success.
>>
>> Do you mean something like this? https://go2goplay.golang.org/p/4I4y-dLC-Yp
>>
>> >
>> > Seems useful to me. A generic balanced tree infrastructure could be 
>> > "meta-instantiated" as a LLRB instance that still allows generic leaf 
>> > types.
>>
>
>
> --
> Michael T. Jones
> michael.jo...@gmail.com
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CALoEmQxTgQdhS2x4MU%3D_FcwBAJ09D68XnNYOQxy5YV7%2B6QOi0w%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANG3jXJ60zyaBsYmvOSJdgX3J%3DaB0_Taz2SnuM31Rg3N0bx8mw%40mail.gmail.com.

Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

[jimmy frasche]

I don't care for the (type T Equaler) example. It makes one thing look
like another.

The rest seems interesting. Obviating and generalizing the * syntax is
certainly promising and a nice justification for type lists.

Would the constraints package have Pointer[E], Slice[E], and so on?

What happens if you have
  type SC(type E I) interface {
type []E
  }
for some I? Generally it seems like something to avoid, but it would
be needed for
  type Map[type K comparable, V interface{}] interface {
type map[K]V
  }
at least. Are those checked at the same time as methods?

Do chains of constraints like
 func F[type T interface{}, PT Setter2[T], SPT SC[PT]](xs SPT) SPT
 func G[type T interface{}, PT Setter2[T], S0 SC[T], S1[PT]](xs S0) S1
work?

On Wed, Aug 12, 2020 at 7:31 PM Ian Lance Taylor  wrote:
>
> I just added a new section to the generics design draft describing
> constraint type inference.  This is a generalization and
> simplification of the earlier pointer method approach, which has now
> been removed.  I would be happy to hear any comments.  Thanks.
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#constraint-type-inference
>
> 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/CAOyqgcX6AcGUt4e6JTMrxXkAtMRq%2Bo6zSVnjqchEroheYBP%2BBw%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANG3jXJme%2BL5FQ5sg600Wi7JORPbSAU%2B%3DG8BN590pnVG859W%2Bg%40mail.gmail.com.

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

[jimmy frasche]

Most of the code I'd write with generics would take a func or
something satisfying an interface to set the operations if necessary.
I'd use type lists as a handy way for the user to default those to
operators. Interface literals and lambdas would be just as useful
here. I probably wouldn't bother writing a min that takes a comparator
but not having min/max has never bothered me as much as not having
things like Tree and Queue.

Type lists do seem like a really good idea but one that isn't quite
fully polished yet. If it's left out of version 1 of generics and
everything else is implemented as is, that would still be incredibly
useful. Even if that only covers 90% of the problem that's still a
lot.

Also +1 on requiring constraints and predeclaring any.

On Wed, Aug 5, 2020 at 10:40 AM Tyler Compton  wrote:
>
> On Wed, Aug 5, 2020 at 1:07 AM Jan Mercl <0xj...@gmail.com> wrote:
>>
>> 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.
>
>
> I think it's fair to say that `interface{}` is somewhat special in practice 
> because it acts as an escape hatch from the type system when necessary. No 
> other interface is capable of being satisfied by values of all types. I 
> assume that the `error` interface is pre-declared because it's a very common 
> interface used across almost all Go code. If `interface{}` is to become even 
> more common than it is thanks to generics, I think it could be reasonable to 
> follow the same thinking.
>
>> Go programmers do avoid casting because Go has no casting. That word
>> or its stem doesn't even appear in the language specs.
>
>
> Something tells me you knew Carla was referring to type assertions.
>
>
> --
> 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/CAA%3DXfu0c-BqTt6vOjbE9ezur0nNNFCSBhgs%3DPFrEUBPASziinw%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANG3jX%2BOWf3usTE%3D7nAXVkardPRd4-ypgtQix6Ean18pTuO6cQ%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[jimmy frasche]

I didn't care about () except for having to then have extra parens
around types in a lot of places which was very annoying and came up
often. If [] fixes that, great!

On Wed, Jul 15, 2020 at 2:47 PM Ian Lance Taylor  wrote:
>
> On Wed, Jul 15, 2020 at 2:36 PM Randall O'Reilly  wrote:
> >
> > Regarding the parsing: as I suggested in my email, but perhaps was unclear, 
> > in case of two conflicting *purely syntactic* interpretations (without 
> > using any type information), you could just choose the more high-frequency 
> > interpretation (i.e., type parameters) and force the programmer to use 
> > additional parens if they actually want the other interpretation.
> >
> > So in the case of the example, w < x, y > (z) is *automatically, 
> > syntactically* interpreted as a function call using 2 type parameters, and 
> > if you want it to be two different relational expressions, you have to wrap 
> > them in parens: (w < x), (y > (z))
> >
> > This latter use is likely to be vanishingly rare (someone could run their 
> > code analysis on it), so this seems like a small inconvenience.  Maybe 
> > there are other such conflicts?  If this is the only one, I don't think it 
> > is sufficient to rule out the use of < >.
> >
> > My mention of the point about gofmt was just that it should get rid of the 
> > seemingly redundant extra paren around (z), but I just tried it and 
> > apparently it does not, even with gofmt -s.  Anyway, the above point 
> > stands: you CAN parse < > correctly by just making purely syntactic choices 
> > in the case of conflicts, and this applies to all Go tools using the same 
> > purely syntactic parsing pass.
>
> That's true.  We could do that.  It's not backward compatible, and it
> doesn't fit the Go 2 transitions plan, but we could do it if we really
> had to.
>
> But we don't really have to.  We can use square brackets instead, or
> we can go back to using parentheses.  This thread suggests that while
> clearly some people prefer angle brackets, it is not a dominant
> consensus.
>
> 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/CAOyqgcVo3d4zrXkGtxPzMUSC%2BJ0ju_B3DsQZj%2B%3D5Ec2%2B3y0%3DSA%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANG3jXLSGAd644zrKUOJL1b%2BXObtrvTnP-tFpYyKgY%3DdUei69w%40mail.gmail.com.

Re: [go-nuts] draft design for // +build replacement

[jimmy frasche]

Running find -name "*_*.go" | xargs grep " +build" on goroot shows a
lot of files with redundant build tags or additional constraints not
present in the file name so they don't seem like much of a single
point of truth.

I'd be fine with removing file names sometimes implying build tags.
Add build tags from the filename to the go:build line and after go1.X
stop getting build tags from the file name.

There would still be special cases like _test and cgo but there would
be fewer special cases. Option 3 looks like a solid plan to handle the
hypothetical _fuzz even if otherwise things converge on go:build.

On Wed, Jul 1, 2020 at 11:20 AM Bakul Shah  wrote:
>
> 4. Use two underscores for constraints. At least new constraints.
>
> Aside: Are you plantin' an idea about Plan10?
>
> On Jul 1, 2020, at 11:06 AM, Russ Cox  wrote:
>
> For what it's worth, I am (unsurprisingly) a big fan of the filename-based 
> constraints. It's a lightweight convention that has served us incredibly 
> well. I really like being able to see in a directory listing which files go 
> with what. It would be unfortunate if we had to put the redundant info inside 
> files and then hope that the info inside matched the file names and/or 
> introduce consistency checks. A single point of truth always seems better to 
> me than verified redundancy.
>
> But I certainly hear your point about what happens when a new OS comes along 
> (plan10, say) and none of the old Go releases know that foo_plan10.go should 
> be ignored except when GOOS=plan10. If we were going to seriously consider 
> fixing the filename-based constraint ambiguity (probably not today), there 
> are at least three possible paths forward.
>
> 1. Remove the ambiguity by making _foo in a filename never a constraint, as 
> you've proposed. For me, this throws the baby out with the bathwater.
>
> 2. Remove the ambiguity by making _foo in a filename always a constraint. If 
> a toolchain doesn't know what foo means, then the constraint is clearly not 
> satisfied. I think this would be too painful to deploy. I ran a scan last 
> night and there are just far too many files using underscores for 
> non-constraints today.
>
> 3. Two steps:
> 3a. Make the go command apply a list based on the go version in go.mod, so 
> that we can say "as of Go 1.16, plan10 is a recognized GOOS". Then when 
> building old code, any existing foo_plan10.go file doesn't get reinterpreted.
> 3b. Remove uncertainty in tools by making them ask the go command (perhaps 
> using x/tools/go/packages), which always knows.
>
> I think I would lean more toward 3 than 1 or 2. As someone noted, we're 
> certainly not going to start requiring //go:build test in every *_test.go 
> file - that convention won't go away. But then what happens when the next 
> thing comes along? What if for fuzzing turns out to be very helpful to have a 
> foo_fuzz.go convention? (Probably not, but what about the next thing?) If we 
> get all the tools asking the go command, then that kind of change is easy to 
> deploy. (Similarly, files with import "C" only apply when the cgo tag is set. 
> I don't think it makes sense for tools to be hard-coding that rule, nor would 
> it make sense at this point to require an explicit //go:build cgo. If tools 
> ask the go command instead of trying to rederive these kinds of things 
> themselves, it's no problem at all.)
>
> I would be very interested to hear about which tools can't ask the go command 
> for this info, and why, and what we can do to address that.
>
> 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/CAA8EjDQbwP6zsmr%2BYHw4hQbVv8c%2BkUvMAMowMb3o_%2B%3DnUu5Z2Q%40mail.gmail.com.
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/443ACF21-0A34-484D-B1E3-273E6226E96C%40iitbombay.org.

-- 
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/CANG3jX%2BKFt4xEEWG3oLa4wEsqEsvEa%2BMCDk9hkBV7R77ESqL2g%40mail.gmail.com.

Re: [go-nuts] [generics] type list suggestion

[jimmy frasche]

> Most people who want sum types don't want the zero value to be nil.

I am certainly one of those people, but, if interfaces with type lists
can be used for sum types and generics constraints, it's well worth
the trade off for keeping the language simple.

My major concern with the current notation is that it may make it too
awkward to change later so type lists would be stuck as
constraint-only. Even if better sum types that I'd be happier with are
added later there would be overlap and footnotes.

On Mon, Jun 22, 2020 at 3:45 PM Ian Lance Taylor  wrote:
>
> On Mon, Jun 22, 2020 at 3:03 PM jimmy frasche  wrote:
> >
> > Fair enough that I'd missed the last sentence.
> >
> > However, if you mark the types that require exact matches you can't
> > reuse the same sigil in type assertion/switches, so it's unclear how
> > those would work.
> >
> > Plus, it just seems backwards since exact is the default everywhere else.
>
> Yes, it's imperfect.  We spent a few weeks looking for a good solution
> here but couldn't find one, so we decided to push forward.  We don't
> want to optimize for sum types, since we're not at all sure that
> interfaces with type lists are suitable for use as sum types.  Most
> people who want sum types don't want the zero value to be nil.
>
> Ian
>
>
> > On Mon, Jun 22, 2020 at 2:40 PM Ian Lance Taylor  wrote:
> > >
> > > On Sat, Jun 20, 2020 at 3:51 PM jimmy frasche  
> > > wrote:
> > > >
> > > > I really like how the latest generics draft has progressed, fantastic
> > > > work. The only thing that doesn't really feel perfect yet is type
> > > > lists.
> > > >
> > > > I like the idea of all constraints being interfaces and I get why
> > > > interfaces with type lists and/or comparable are only constraints for
> > > > now. I'd rather they be valid interfaces. For comparable that has a
> > > > natural definition [1], but for type lists it's less obvious.
> > > >
> > > > [1] https://github.com/golang/go/issues/27481
> > > >
> > > > If an interface with a type list is used as a sum type, it generally
> > > > would want to restrict on exact type identity, just like a constraint
> > > > generally does not want exact type identity. It would be strange if
> > > > how the type list matched changed based on context.
> > > >
> > > > What if type lists could specify for each type whether it wants exact
> > > > identity or the kind used in the draft?
> > > >
> > > > Since this is similar to the difference between
> > > >   type A B
> > > > and
> > > >   type A = B
> > > > I'll use
> > > >   type =X, Y
> > > > to mean X is matched using the rules in the draft but Y must exactly
> > > > match, so every example in the draft would need to be prefixed.
> > > >
> > > > Type assertions and switches could use this notation:
> > > >   type Str string
> > > >   var i interface{} = Str("x")
> > > >   s, ok := i.(=string) // ok is true, s is type string
> > > >
> > > >   switch v.(type) {
> > > >   case =float32, =float64:
> > > >   case string:
> > > >   case =string:
> > > >   }
> > > > (probably the = variety would only be for interfaces with type lists
> > > > or perhaps only in generic code).
> > > >
> > > > It would be rare to want to use exact matches in interfaces as
> > > > constraints and rare to use underlying matches in interfaces as
> > > > values, but this would let both cases be handled uniformly yet
> > > > distinctly.
> > >
> > > https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-lists-in-interface-types
> > >
> > > 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/CANG3jXLPX69%2BdQzhnCT78KVHmrCM8N%3DkEoV2o5pScWLLdN35bA%40mail.gmail.com.

Re: [go-nuts] [generics] type list suggestion

[jimmy frasche]

Fair enough that I'd missed the last sentence.

However, if you mark the types that require exact matches you can't
reuse the same sigil in type assertion/switches, so it's unclear how
those would work.

Plus, it just seems backwards since exact is the default everywhere else.

On Mon, Jun 22, 2020 at 2:40 PM Ian Lance Taylor  wrote:
>
> On Sat, Jun 20, 2020 at 3:51 PM jimmy frasche  wrote:
> >
> > I really like how the latest generics draft has progressed, fantastic
> > work. The only thing that doesn't really feel perfect yet is type
> > lists.
> >
> > I like the idea of all constraints being interfaces and I get why
> > interfaces with type lists and/or comparable are only constraints for
> > now. I'd rather they be valid interfaces. For comparable that has a
> > natural definition [1], but for type lists it's less obvious.
> >
> > [1] https://github.com/golang/go/issues/27481
> >
> > If an interface with a type list is used as a sum type, it generally
> > would want to restrict on exact type identity, just like a constraint
> > generally does not want exact type identity. It would be strange if
> > how the type list matched changed based on context.
> >
> > What if type lists could specify for each type whether it wants exact
> > identity or the kind used in the draft?
> >
> > Since this is similar to the difference between
> >   type A B
> > and
> >   type A = B
> > I'll use
> >   type =X, Y
> > to mean X is matched using the rules in the draft but Y must exactly
> > match, so every example in the draft would need to be prefixed.
> >
> > Type assertions and switches could use this notation:
> >   type Str string
> >   var i interface{} = Str("x")
> >   s, ok := i.(=string) // ok is true, s is type string
> >
> >   switch v.(type) {
> >   case =float32, =float64:
> >   case string:
> >   case =string:
> >   }
> > (probably the = variety would only be for interfaces with type lists
> > or perhaps only in generic code).
> >
> > It would be rare to want to use exact matches in interfaces as
> > constraints and rare to use underlying matches in interfaces as
> > values, but this would let both cases be handled uniformly yet
> > distinctly.
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-lists-in-interface-types
>
> 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/CANG3jX%2BZuOxvOd%2BLzXLXVO1uVZvrwKmGiMZBBDDMebNNS0T%2Bxg%40mail.gmail.com.

[go-nuts] [generics] type list suggestion

[jimmy frasche]

I really like how the latest generics draft has progressed, fantastic
work. The only thing that doesn't really feel perfect yet is type
lists.

I like the idea of all constraints being interfaces and I get why
interfaces with type lists and/or comparable are only constraints for
now. I'd rather they be valid interfaces. For comparable that has a
natural definition [1], but for type lists it's less obvious.

[1] https://github.com/golang/go/issues/27481

If an interface with a type list is used as a sum type, it generally
would want to restrict on exact type identity, just like a constraint
generally does not want exact type identity. It would be strange if
how the type list matched changed based on context.

What if type lists could specify for each type whether it wants exact
identity or the kind used in the draft?

Since this is similar to the difference between
  type A B
and
  type A = B
I'll use
  type =X, Y
to mean X is matched using the rules in the draft but Y must exactly
match, so every example in the draft would need to be prefixed.

Type assertions and switches could use this notation:
  type Str string
  var i interface{} = Str("x")
  s, ok := i.(=string) // ok is true, s is type string

  switch v.(type) {
  case =float32, =float64:
  case string:
  case =string:
  }
(probably the = variety would only be for interfaces with type lists
or perhaps only in generic code).

It would be rare to want to use exact matches in interfaces as
constraints and rare to use underlying matches in interfaces as
values, but this would let both cases be handled uniformly yet
distinctly.

-- 
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/CANG3jXKs_CPymGd0GnMw_g1COH%2Bkc-pJcqmkHWSG%2BEnqMp9VaA%40mail.gmail.com.

Re: [go-nuts] [generics] the empty type list

[jimmy frasche]

I think I'm missing something. How is nil not an inhabitant?

On Thu, Jun 18, 2020 at 6:48 PM Bryan C. Mills  wrote:
>
> On Thu, Jun 18, 2020 at 4:19 PM 'Axel Wagner' via golang-nuts 
>  wrote:
>>
>> Addendum: In Go, every type needs to be inhabited by at least one value - 
>> it's zero value. And we already have a type that can take *exactly* one 
>> value, namely struct{}.
>
>
> That is true, but struct{} is the unit type — not the bottom element of the 
> interface-type lattice.
> struct{} can be added as a field of any struct with no effect on 
> comparability or equality, and adds no bits of information (it is a 
> multiplicative unit).
> As an interface value, struct{} carries one “bit” of information: its type.
> But struct{} has no methods and is not assignable to any interface type: 
> therefore, it is not the bottom type of the interface lattice.
>
> In contrast, the interface of the empty type-list, if such a thing could 
> exist at run-time, would presumably have only one value as well: the nil 
> interface value.
> The nil interface value is a member of every other interface type, so the 
> empty type-list would be assignable to every other interface type (it is the 
> bottom of the interface lattice).
> Conceptually, it has all possible methods, but there would be no point in 
> calling them: they all result in a nil-panic.
> As a struct field, the empty interface is also a multiplicative unit (it adds 
> no bits of information).
> However, it is also an additive unit: the union of the empty type-list and 
> any other interface is identical to the other interface (because every other 
> interface already admits the nil interface value).
>
>> On Thu, Jun 18, 2020, 22:13 Axel Wagner  
>> wrote:
>>>
>>> These arguments would be more convincing, if Go wouldn't already reject 
>>> interfaces impossible to implement: https://play.golang.org/p/dYm8js26qml
>>>
>>> On Thu, Jun 18, 2020, 17:26 Jesper Louis Andersen 
>>>  wrote:
>>>>
>>>> It is a type which cannot be inhabited by a term. These exist and often 
>>>> have uses. As Bryan wrote they also completes the type lattice, so 
>>>> rejecting them is often a lot of work for little gain.
>>>>
>>>> If you want examples, look up phantom types, where an uninhabited type is 
>>>> used as a tag for ensuring compile time restrictions.
>>>>
>>>> On Wed, Jun 17, 2020, 22:09 jimmy frasche  wrote:
>>>>>
>>>>> This isn't a bug per se, but I can file one if requested.
>>>>>
>>>>> https://go2goplay.golang.org/p/AWynhg6ya7h
>>>>>
>>>>> Since embedding interfaces with type lists uses the intersection of
>>>>> the items in the type list, it's possible to create an interface that
>>>>> cannot be satisfied by any type.
>>>>>
>>>>> Currently this does not cause an error until you attempt to
>>>>> instantiate something that uses such an interface as a bound.
>>>>>
>>>>> I think it would be more useful to raise the error when defining the
>>>>> interface that cannot be used as it's likely an error—or at least I
>>>>> can see no valid use for creating an unsatisfiable constraint.
>>>>>
>>>>> --
>>>>> 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/CANG3jXJt_n1HrRMV1SBcaurXOrXVJxXrKN_F%3DtgMAcMJ%2BPOLcg%40mail.gmail.com.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups 
>>>> "golang-nuts" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>>> email to golang-nuts+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVPP21fky2qcgfnAYjH6H047C1A0Y_V%3Doa%3DB3pTWRX68g%40mail.gmail.com.
>>
>> --
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/CsA1FJKZ4qs/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFwkVmbva1bRYbHX3D6oUhufHvdr-Ebb0GY0u3j_fyTUA%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANG3jXJX0gf%3D%3DniCa4MtQ7-3Q6rU%3DQr2tTpKntMVMqDVOo4BMw%40mail.gmail.com.

Re: [go-nuts] [generics] the empty type list

[jimmy frasche]

The constraint can't be used for phantom types. If C is an interface
with an empty type list and P is given by
type P(type T C) struct{}
you can't instantiate P because no type can satisfy C.

C is not the type with 0 inhabitants: it's a constraint on types that
cannot be satisfied.

I don't see how it can be used in any valid program or why it would be
hard to detect. I am a little fuzzy on when type lists bring the
underlying type into play, though.

On Thu, Jun 18, 2020 at 1:17 PM Axel Wagner
 wrote:
>
> Addendum: In Go, every type needs to be inhabited by at least one value - 
> it's zero value. And we already have a type that can take *exactly* one 
> value, namely struct{}.
>
> On Thu, Jun 18, 2020, 22:13 Axel Wagner  wrote:
>>
>> These arguments would be more convincing, if Go wouldn't already reject 
>> interfaces impossible to implement: https://play.golang.org/p/dYm8js26qml
>>
>> On Thu, Jun 18, 2020, 17:26 Jesper Louis Andersen 
>>  wrote:
>>>
>>> It is a type which cannot be inhabited by a term. These exist and often 
>>> have uses. As Bryan wrote they also completes the type lattice, so 
>>> rejecting them is often a lot of work for little gain.
>>>
>>> If you want examples, look up phantom types, where an uninhabited type is 
>>> used as a tag for ensuring compile time restrictions.
>>>
>>> On Wed, Jun 17, 2020, 22:09 jimmy frasche  wrote:
>>>>
>>>> This isn't a bug per se, but I can file one if requested.
>>>>
>>>> https://go2goplay.golang.org/p/AWynhg6ya7h
>>>>
>>>> Since embedding interfaces with type lists uses the intersection of
>>>> the items in the type list, it's possible to create an interface that
>>>> cannot be satisfied by any type.
>>>>
>>>> Currently this does not cause an error until you attempt to
>>>> instantiate something that uses such an interface as a bound.
>>>>
>>>> I think it would be more useful to raise the error when defining the
>>>> interface that cannot be used as it's likely an error—or at least I
>>>> can see no valid use for creating an unsatisfiable constraint.
>>>>
>>>> --
>>>> 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/CANG3jXJt_n1HrRMV1SBcaurXOrXVJxXrKN_F%3DtgMAcMJ%2BPOLcg%40mail.gmail.com.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to golang-nuts+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVPP21fky2qcgfnAYjH6H047C1A0Y_V%3Doa%3DB3pTWRX68g%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANG3jX%2BESnanNyPBdDdQdc_uZMFzU-h3fMRGqB01M-RJVtnSaQ%40mail.gmail.com.

Re: [go-nuts] [generics] the empty type list

[jimmy frasche]

I think that second error is a bug. I would expect that case to be the
same as if I wrote a type list that was just int (and hence not the
empty type list).

On Wed, Jun 17, 2020 at 4:33 PM jimmy frasche  wrote:
>
> If I merge the two examples I still get an error
> https://go2goplay.golang.org/p/TNYLDLokGCQ
>
> prog.go2:21:2: int does not satisfy Z (int not found in ⊥)
>
> On Wed, Jun 17, 2020 at 4:24 PM Ian Lance Taylor  wrote:
> >
> > On Wed, Jun 17, 2020 at 3:52 PM jimmy frasche  
> > wrote:
> > >
> > > The only case I mean is when the intersection of the type lists is ∅.
> > > That's easy to check and always wrong afaict.
> >
> > Unfortunately I don't think it's that simple.
> >
> > type MyInt int
> >
> > type I1 interface {
> > type int
> > }
> >
> > type I2 interface {
> > type MyInt
> > }
> >
> > type I3 interface {
> > I1
> > I2
> > }
> >
> > It might seem like the intersection of the type lists in I1 and I2 is
> > the empty set, but since we match on underlying types I3 does match
> > "int".
> >
> > Ian
> >
> >
> > > On Wed, Jun 17, 2020 at 3:47 PM Ian Lance Taylor  wrote:
> > > >
> > > > On Wed, Jun 17, 2020 at 1:09 PM jimmy frasche  
> > > > wrote:
> > > > >
> > > > > This isn't a bug per se, but I can file one if requested.
> > > > >
> > > > > https://go2goplay.golang.org/p/AWynhg6ya7h
> > > > >
> > > > > Since embedding interfaces with type lists uses the intersection of
> > > > > the items in the type list, it's possible to create an interface that
> > > > > cannot be satisfied by any type.
> > > > >
> > > > > Currently this does not cause an error until you attempt to
> > > > > instantiate something that uses such an interface as a bound.
> > > > >
> > > > > I think it would be more useful to raise the error when defining the
> > > > > interface that cannot be used as it's likely an error—or at least I
> > > > > can see no valid use for creating an unsatisfiable constraint.
> > > >
> > > > In order to ensure that all Go compilers act the same, we would have
> > > > to very carefully define the cases that are not accepted.  This is a
> > > > little harder than it sounds since matching is done on underlying
> > > > types.  At least for now I tend to think that it would be better to
> > > > make this a vet check.  But I don't feel all that strongly about it.
> > > >
> > > > 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/CANG3jX%2BH_kDpcba2VUwSv4RhBAFV4_ufN1JiRb6KNZ1BphRriA%40mail.gmail.com.

Re: [go-nuts] [generics] the empty type list

[jimmy frasche]

If I merge the two examples I still get an error
https://go2goplay.golang.org/p/TNYLDLokGCQ

prog.go2:21:2: int does not satisfy Z (int not found in ⊥)

On Wed, Jun 17, 2020 at 4:24 PM Ian Lance Taylor  wrote:
>
> On Wed, Jun 17, 2020 at 3:52 PM jimmy frasche  wrote:
> >
> > The only case I mean is when the intersection of the type lists is ∅.
> > That's easy to check and always wrong afaict.
>
> Unfortunately I don't think it's that simple.
>
> type MyInt int
>
> type I1 interface {
> type int
> }
>
> type I2 interface {
> type MyInt
> }
>
> type I3 interface {
> I1
> I2
> }
>
> It might seem like the intersection of the type lists in I1 and I2 is
> the empty set, but since we match on underlying types I3 does match
> "int".
>
> Ian
>
>
> > On Wed, Jun 17, 2020 at 3:47 PM Ian Lance Taylor  wrote:
> > >
> > > On Wed, Jun 17, 2020 at 1:09 PM jimmy frasche  
> > > wrote:
> > > >
> > > > This isn't a bug per se, but I can file one if requested.
> > > >
> > > > https://go2goplay.golang.org/p/AWynhg6ya7h
> > > >
> > > > Since embedding interfaces with type lists uses the intersection of
> > > > the items in the type list, it's possible to create an interface that
> > > > cannot be satisfied by any type.
> > > >
> > > > Currently this does not cause an error until you attempt to
> > > > instantiate something that uses such an interface as a bound.
> > > >
> > > > I think it would be more useful to raise the error when defining the
> > > > interface that cannot be used as it's likely an error—or at least I
> > > > can see no valid use for creating an unsatisfiable constraint.
> > >
> > > In order to ensure that all Go compilers act the same, we would have
> > > to very carefully define the cases that are not accepted.  This is a
> > > little harder than it sounds since matching is done on underlying
> > > types.  At least for now I tend to think that it would be better to
> > > make this a vet check.  But I don't feel all that strongly about it.
> > >
> > > 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/CANG3jXKE6EksKcgvPXWiP9naCXAwbc7LMihvJeDw1fatPXgS%3Dg%40mail.gmail.com.

Re: [go-nuts] [generics] the empty type list

[jimmy frasche]

The only case I mean is when the intersection of the type lists is ∅.
That's easy to check and always wrong afaict.

On Wed, Jun 17, 2020 at 3:47 PM Ian Lance Taylor  wrote:
>
> On Wed, Jun 17, 2020 at 1:09 PM jimmy frasche  wrote:
> >
> > This isn't a bug per se, but I can file one if requested.
> >
> > https://go2goplay.golang.org/p/AWynhg6ya7h
> >
> > Since embedding interfaces with type lists uses the intersection of
> > the items in the type list, it's possible to create an interface that
> > cannot be satisfied by any type.
> >
> > Currently this does not cause an error until you attempt to
> > instantiate something that uses such an interface as a bound.
> >
> > I think it would be more useful to raise the error when defining the
> > interface that cannot be used as it's likely an error—or at least I
> > can see no valid use for creating an unsatisfiable constraint.
>
> In order to ensure that all Go compilers act the same, we would have
> to very carefully define the cases that are not accepted.  This is a
> little harder than it sounds since matching is done on underlying
> types.  At least for now I tend to think that it would be better to
> make this a vet check.  But I don't feel all that strongly about it.
>
> 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/CANG3jX%2BZ1H8YUaSFFTPmV-CUQgKbkWBFU48vAO6aO-Ad-p%2BuNw%40mail.gmail.com.

[go-nuts] [generics] the empty type list

[jimmy frasche]

This isn't a bug per se, but I can file one if requested.

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

Since embedding interfaces with type lists uses the intersection of
the items in the type list, it's possible to create an interface that
cannot be satisfied by any type.

Currently this does not cause an error until you attempt to
instantiate something that uses such an interface as a bound.

I think it would be more useful to raise the error when defining the
interface that cannot be used as it's likely an error—or at least I
can see no valid use for creating an unsatisfiable constraint.

-- 
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/CANG3jXJt_n1HrRMV1SBcaurXOrXVJxXrKN_F%3DtgMAcMJ%2BPOLcg%40mail.gmail.com.

Re: [go-nuts] Contracts and fused multiply add

[jimmy frasche]

If the contract further specified that the type must be ordered
without restricting it to just floating-point you could feature test

var d T = 3
if d/2 != 1 {
  // T is floatX
  if unsafe.Sizeof(d)  == 4 {
// float32
  } else {
// float64
  }
}

Similarly, you could test for unsigned with

var z T
if z - 1 > 0 {
  // T is uintX
} else {
  // T is intX or floatX
}

In both cases you have to kick out the complex numbers. Combined you
have a means of classifying the properties of the types that satisfy a
basic ordered arithmetic contract without having to use reflection or
unsafe.

Not especially readable, but it could be pulled out into a generic predicate:

contract Number(t T) {  t - t < t }

const (
  Int = iota
  Uint
  Float
)

func Kind(type T Number)(_ T) int {
  if T(3)/2 != 1 {
return Float
  } else if T(0) - 1 > 0 {
return Uint
  }
  return Int
}

With that you could write the must-FMA version as:

func maMustFMA(type T Number)(a, b, c T) T {
if Kind(a) == Float {
  return T(math.Fma(float64(a), float64(b), float64(c)))
}
return a*b + c
  }
}

On Wed, Sep 12, 2018 at 11:08 AM jimmy frasche  wrote:
>
> On Wed, Sep 12, 2018 at 11:02 AM Ian Lance Taylor  wrote:
> > You could perhaps choose an implementation based on unsafe.Sizeof.
> > But I agree that it's pretty ugly.
>
> Only if the contract were t * t + t < .1
>
> Part of the construction was that it accepted more than just floating points.

-- 
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] Contracts and fused multiply add

[jimmy frasche]

On Wed, Sep 12, 2018 at 11:02 AM Ian Lance Taylor  wrote:
> You could perhaps choose an implementation based on unsafe.Sizeof.
> But I agree that it's pretty ugly.

Only if the contract were t * t + t < .1

Part of the construction was that it accepted more than just floating points.

-- 
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] Contracts and fused multiply add

[jimmy frasche]

Given a platform that supports the fused multiply add (FMA)
instruction and the code:

  contract MA(t T) {
t * t + t
  }

  func ma(type T MA)(a, b, c T) T {
return a*b + c
  }

Does the compiled-for-any-type version support the FMA optimization
when called with a floating-point type?

If not, does a specialized version, making the two different based on
whether the compiler chooses to specialize the function?

If I specifically want to not use the optimization when instantiated
with floats, can I do:

  func maNoFMA(type T MA)(a, b, c T) T {
return T(a*b) + c
  }

If I need it to use the guaranteed FMA intrinsic (see
https://github.com/golang/go/issues/25819 ) when instantiated with
floats, I can't do

  func maMustFMA(type T MA)(a, b, c T) T {
switch a.(type) {
case float32:
  return T(math.Fma(
float64(a.(float32)),
float64(b.(float32)),
float64(c.(float32)),
  ))
case float64:
  return T(math.Fma(a.(float64), b.(float64), c.(float64)))
}
return a*b + c
  }

because that misses cases like
  type Float float64
so I have to use reflect which can't be dead-code eliminated during
specialization.

I'm sure there are other cases where similar questions could be asked,
but this seems like a good proxy for the whole class.

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

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

[jimmy frasche]

I think it would work with interfaces if the interfaces (generic or
not) can themselves specify generic methods, like

interface {
  Foo(type T)(T) T
}

You need to be able to invoke methods on a generic type where the
method is not specialized for the instantiation so I don't see why it
should cause any issues with reflection beyond what's required anyway.


On Tue, Sep 11, 2018 at 1:39 PM roger peppe  wrote:
>
> On 11 September 2018 at 18:04, roger peppe  wrote:
> > If it were not explicitly prohibited by the draft proposal, we could
> > also imagine this, a definition of a method foo on the type A that's
> > parameterised with type T; the method itself has a type parameter S:
> >
> > func (a A(T)) foo(type S)(s S, t T)
>
> With respect to this, I wonder if the draft proposal isn't being a bit
> more restrictive than necessary.
>
> I suspect that type parameters on methods might turn out to be very
> nice to have (it's very useful to keep within a type's namespace) even
> if we can't use them in interfaces or in reflect.
>
> How about allowing them, but say that methods with type parameters
> never appear in any interface and cannot be accessed with reflect?
>
> --
> 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.

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

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

[jimmy frasche]

There are two parts to interfaces.

The interface value—the box that things are stored in at runtime.

The interface type—the specification for what things you are allowed
to put in that box at compile time.

Using the interface type to constrain type parameters at compile-time
does not necessarily imply using the interface value to implement
generics at runtime.
On Tue, Sep 11, 2018 at 6:26 AM 'Axel Wagner' via golang-nuts
 wrote:
>
> 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 
> particular, the constraint solver and type-checker for what I described is 
> trivial to write and understand, including good error messages. AIUI it is 
> currently not clear whether the contract design can actually be type-checked 
> in practice (and, personally, I am predicting the things I and others are 
> bringing up to be exactly the things that will come up as difficultlies).
>
>>
>> Re-using interfaces seems like it would mandate boxing, (or interfaces are 
>> no longer interfaces as currently described, which would also be a major 
>> change).
>
>
> That is not true. If interfaces are used to specify constraints, they mandate 
> boxing just as little or as much as contracts do. That should be obvious in 
> any case, given that you can always write an interface constraint as a 
> contract via
>
> contract SomeInterfaceContract(v T) {
> var _ SomeInterface = v
> }
>
> In general, I don't believe there is any difference - the question of boxing 
> or not boxing is an implementation detail. Currently, there is nothing in the 
> spec that requires boxing to happen here:
>
> func Foo(w io.Writer) { fmt.Fprintln(w, "Hello world") }
> func main() { Foo(os.Stdout) }
>
> The compiler could decide to devirtualize the interface, to generate a boxed 
> version or to do a hybrid approach (e.g. compile a boxed version and 
> devirtualize for certain types based on usage). Exactly like with the 
> contract designs.
>
> Or, as I phrased it elsewhere: If a compiler can generate an instantiated 
> version of a parametric function Foo(type T) for a call Foo(v), it has to be 
> able to prove the type of v statically. In that case, it can also create a 
> devirtualized version of a hypothetical not parametric Foo(v interface{}).
>
> I don't believe that there is any performance benefit to generics in the 
> general case, except where type-parameters and constraints can be used to 
> prove tighter bounds on the static types used - and in that case, it doesn't 
> matter how those constraints are expressed.
>
>> The original generic types and functions as described would permit unboxed, 
>> direct access to fields, without relying on inlining, which can't be 
>> achieved with the interface approach.
>
>
> This is true, but misleading. If the compiler can generate code to do a 
> direct access of a struct field, it needs to know the static type of the 
> passed argument to know the offset of the field. In that case, it can also 
> trivially devirtualize and inline the access.
> i.e. on the one hand, yes, it can't be done "without relying on inlining", 
> but to do it, you need to do the equivalent thing.
>
> FWIW: In practice, the most likely implementation (look for "dual 
> implementation") for struct-field-accesses will be to pass an implicit, 
> autogenerated closure (or some equivalent data) which is pretty much 
> identical to using an interface.
>
> In other words, I'm fairly sure that using interfaces to specify constraints 
> is also satisfying the dual implementation property outlined by Russ.
>
>> Whilst contracts do introduce some ambiguities, it's not obvious that these 
>> are of genuine practical concern.
>
>
> I would respond that, just as much, while interfaces+ as constraints do lack 
> some power that contracts can provide, it's not obvious that these are 
> practically useful things to express :)
>
> Note that all the added power of contracts come from exactly the things where 
> ambiguities arise (namely builtin functions, statements like range and some 
> ambiguous operators). If the ambiguous situations won't come up in practice, 
> I contest that we need the power to express them. If they do, I'd argue that 
> we want them to be easy to understand and unambiguous.
>
>> Ian has pointed out before, this isn't really any different from types that 
>> coincidentally support an interfaces method set, sort.Sort will not do 
>> anything useful if you're types doesn't implement the correct semantic 
>> contract required. It's not obvious that contracts should attempt to be any 
>> more accurate.
>
>
> I respectfully disagree (I think) with Ian that it doesn't matter. One of the 
> main reasons to introduce generics is to get type safe generics and type 
> safety is 

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

[jimmy frasche]

On Sun, Sep 9, 2018 at 12:46 AM Ian Lance Taylor  wrote:
> To me contracts aren't implicit or roundabout at all, at least not
> when it comes to which types they permit.  They are very direct and
> straightforward, and they really could not be simpler.  But clearly
> many people disagree.  Perhaps we need to make them more complex by
> turning them into a list of explicit constraints.

I realized there's a kind of ambiguity in the conversation here.

There are two cases for what types a fixed contract C allows. Let's
say that F is some generic func over C.

The first is I have this type T, can I call F with it? This case is
easy because you can look at T and C check off each property.

The other is I need to use F so what are the possible T I can
construct. This is where it's less clear what the options are when C
constrains basic types. Operators are overloaded and there a multitude
of special cases for basic types. While this overloading and these
special cases make it simple to use a specific basic type, they make
it hard to work backwards from a list of properties and see what
options are available. Looking at contract stringable(s T) { string(s)
}, it's not immediately obvious that int is admissible.

With interfaces both cases are the same because it's a set of
unambiguous methods.

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

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

[jimmy frasche]

> > I get that it avoids introducing those properties directly into the
> > language but it also locks the language into those properties. You can
> > never change https://github.com/golang/go/issues/19113 after
> > introducing contracts because there could be a contract somewhere that
> > uses 1 << u instead of contracts.Unsigned.
>
> This is an interesting point but I'm not yet convinced.  The effect of
> adopting issue 19113 would be that the contract would accept types
> that it previously did not accept.  But any polymorphic function using
> that contract would still compile.  And any call to that polymorphic
> function would still compile and work correctly.  So what you are
> arguing is that we could not make a change that would cause a contract
> to accept additional types.  I've been questioning why it is important
> for a contract to reject types, and I'm still questioning that.

That's true, it would be somewhat analogous to removing a method from
an interface. It still accepts all the types it previously accepted
and accepts more.

The analogy breaks down because code calling the removed method would
break if it attempted to call the now missing method.

Generic code satisfying the contract that relied on the property that
m - n > 0 for all m, n would continue to run in the absence of this
now missing property when instantiated with a signed number. Though it
may not do so correctly. Unlike the missing method, the missing
property is harder to detect.

It's easy to detect 1 << u in contracts but unless you know that it
was written previous to the version of Go that allowed signed shifts
you can't update it to contracts.Unsigned(u). If it was written later
it could just mean "any integral number and I'm using it as the amount
to shift by". To avoid the polysemy, you have to use the contracts
package from the start.

You avoid adding the notion of unsigned-ness into the language
directly but by creating a mechanism that, for the built in types, can
effectively only be used by the standard library.

Contracts would definitely disallow a change like
https://github.com/golang/go/issues/24529

That's a backwards-incompatible change now but it's rarely used and
easy to detect and to automatically fix. After contracts it would
likely be as rarely used but much harder to detect and automatically
fix.

> I guess that by special rules you mean the fact that == permits !=,
> and that < permits other comparison operators.  Are there other
> special rules you mean?  These rules seem to confuse people and I'm
> increasingly inclined to think that we should just drop them.

If you drop them that simplifies things but also creates further
reliance on the contracts package since no one is going to want to
enumerate all comparisons used when they can just say
contracts.Ordered(T).

It also means that you can have contracts like

  contract Less(t T) { t < t }
  contract Greater(t T) { t > t }

While these accept exactly the same types, they accept completely
different code in the implementation.

> It is like solving a puzzle because you are trying to figure out how
> to exclude some types.  Why are you doing that?  Why not just describe
> the types you accept, and not worry about other types?  Just as we do
> for interface types?

> To me contracts aren't implicit or roundabout at all, at least not
> when it comes to which types they permit.  They are very direct and
> straightforward, and they really could not be simpler.  But clearly
> many people disagree.  Perhaps we need to make them more complex by
> turning them into a list of explicit constraints.

This is an artificial example that I would hope never comes up in
practice, but if you bear with me on it I think it illustrates several
points:

  contract complex(s S, t T) {
s.F[t] > <-t.G(s)
  }

This is clearly written in code golf style. It can be written more
explicitly as:

  contract complex(s S, t T) {
var fieldF = s.F
var indexResult = fieldF[t]

var selG = t.G
var invocationResult = selG(s)
var channelResult = <-invocationResult

indexResult > channelResult
  }

To be fair, I said more explicitly—not more clearly!

You can't use the contracts package to simplify this because
indexResult and channelResult aren't types, they're values of an
unspecified type that is entirely implicit in the contract definition.
So if < doesn't imply the other operators on ordered types you have to
do

  contract complex(s S, t T) {
var a = s.F[t]
var b = <-t.G(s)
a == b
a != b
a < b
// etc.
  }

You could introduce a third type parameter like
  contract complex(s S, t T, _ U) {
var a U = s.F[t]
var b U = <-t.G(s)
contracts.Comparable(U)
  }

But in addition to having an extra, arguably useless type parameter to
carry around, this is a different contract. It only asserts that
s.F[t] and <-t.G(s) are assignable to U whereas the original asserted
they were identical types (arguably fine).

You could special 

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

[jimmy frasche]

"Any unsigned number" would allow generic versions of the math/bits
functions, though they'd have to dispatch on unsafe.Sizeof internally,
as a type switch would miss
  type Uint uint
But that would presumably be DCE'd if specialized.

Allowing more types than intended isn't always bad. If I have code
that takes a string but I also want it to work on types like
  type String string
the contact for that has to be
  contract stringy(s T) {
string(s)
len(s)
  }
to avoid allowing rune and byte. This is necessary because my code
also has to satisfy the contract. This also accepts []rune and []byte
and that's fine in this case since the code will be using immutable
values. Here it's kind of a nice bonus.

It does seem like writing contracts from scratch will be difficult. If
I want something that works on slice-y things I might attempt:
  contract slicey(s T) {
s[0]
  }
  func rest(type S slicey)(sliceable S) S {
return sliceable[1:]
  }
But that will fail to compile because that contract isn't equivalent
to sliceable things: it's equivalent to
  for _, _ = range s {}
which is things that can be iterated over that are not channels.

The contract should have been
  s[:0]
which is limited to arrays, slices, and strings.

But then the contract accepts [0]T but the code requires at least [1]T
so either the final contract is
  s[1:]
or the minimum array size has to be inferred contradicting the premise
of the contract to specify all the constraints on both the acceptable
types and the implementation. The contract could be changed to
  make(T, 0)[:0]
which disallow arrays but that also disallows strings.

At that point, it would be simpler to just do
  func rest(type T)(slice []T) T {
return slice[1:]
  }

While I don't see a way to express that contract, I can see how to
enforce that a struct type has fields A, B, and C in alphabetical
order:
  contract superUseful(t T) {
[unsafe.Offsetof(t.C) - unsafe.Offsetof(t.B)]struct{}
[unsafe.Offsetof(t.B) - unsafe.Offsetof(t.A)]struct{}
  }
(Assuming the size of each fields is greater than 0; based on
https://twitter.com/lukechampine/status/1013635527801786369 )

No one would write that, except in a "guess what this does!" format, of course.

If there's a contracts package, it would be easier to use contracts.
But my guess then is that a lot of the nonempty contracts in the wild
would match one of these patterns:
  contract simple(t T) {
someInterface(t)
  }

  contract simple2(t T) {
contracts.Comparable(t)
someInterface(t)
  }

  contract complex(t T) {
contracts.PropertyA(t)
contracts.PropertyB(t)
contracts.PropertyC(t)
contracts.PropertyD(t)
contracts.PropertyE(t)
contracts.PropertyF(t)
  }

I get that it avoids introducing those properties directly into the
language but it also locks the language into those properties. You can
never change https://github.com/golang/go/issues/19113 after
introducing contracts because there could be a contract somewhere that
uses 1 << u instead of contracts.Unsigned.

> >   struct{ io.Reader; T}{}.Read
>
> Just to make it worse, T would be permitted if T is a struct with an
> embedded field that has a Read method.

That extra level of nesting would still result in the selector Read
being ambiguous causing the contract to reject T.

> It's not clear to me why anybody would write a contract like this.

If you allow embedding a type parameter in a generic struct, you need
that contract to assert that the embedded type parameter does not
conflict with an embedded regular type's selectors or you can't use
them in the methods of the type since they're not always present. You
only need that for selectors you use but any you don't assert like
that can disappear depending on the parameterization so you can have
weird cases where a generic type satisfies an interface unless
instantiated with a type that also satisfies that interface.
On Sat, Sep 8, 2018 at 7:06 AM alanfo  wrote:
>
> OK, fair enough, but the only way you could have a standard package on those 
> lines without the compiler doing more inference would be to list expressions 
> for every single operator or conversion that the relevant types support. That 
> should be doable but I'm not sure whether a particular built-in type (or 
> group of such types) would be completely defined in this way or whether it 
> would matter if it wasn't.
>
> Anyway, it's an idea to work on.
>
> Alan
>
> --
> 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.

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

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

[jimmy frasche]

On Fri, Sep 7, 2018 at 6:10 AM Ian Lance Taylor  wrote:
>
> On Thu, Sep 6, 2018 at 4:29 PM, Axel Wagner
>  wrote:
> >
> > The other day I had a lengthy conversation with Rog Peppe, David Crawshaw
> > and Nate Finch on twitter and I'd argue that neither of us would really
> > count as a Go-novice and we *still* weren't always clear what types certain
> > contracts allowed and excluded.
>
> 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.  It's true that sometimes this can be a surprising type,
> but to me that seems just like the fact that it can be surprising
> which types implement an interface.
>
> What I agree is less clear is which generic function bodies are
> permitted by a given contract.  That requires more thought.
>
> Ian

I think the major problem is that all the operations depend on their
context . Individually they can mean many different things.

It's very easy to know what a[0] means given the context that a is a
slice but contracts take the context away. That could be a slice or a
map with an integral key type.

To describe a sufficiently-tight contract you need to be able to come
up with an elaborate conjunction of properties that allow everything
needed while disallowing everything that would cause your code to
break. To read such a contract, you need to be able to know all the
rules involved and to be able to run the solver in your head that
says: okay X, Y, Z can do A. X and Y can do B. And Y and Z can do C.
Ah, so it must be Y.

Maybe it would be easier if there were a way to specify negative
requirements like

  a[0] but not a["s"]

so it would be easier to express and understand what you cannot do.
That of course introduces even more complexity, though.

In the generics thread, we were talking about embedding type arguments
and what would happen if you embedded a regular type and a type
argument. If that's allowed that would cause issues when a selector in
the type argument and the regular type collided so the contract would
need to be

  struct{ io.Reader; T}{}.Read

To express that T cannot have a Read selector. That's a somewhat
subtle contract to write and to read. Once you know what it means and
memorize the pattern it's clear, but it would be a hard ask to wake
someone up in the middle of the night who's never seen it and have
them explain the implications.

Any contract that's more than a few lines is going to need a large
comment explaining what is and is not allowed by the contract. While
you have to do that with properties of values inexpressible in the
type system anyway but I don't think you should have to do that for
what should amount to "any unsigned integral 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.
For more options, visit https://groups.google.com/d/optout.

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

[jimmy frasche]

> > Hypothetically, if Go introduced generics where you couldn't write
> > min/max but included min/max builtins, what's the next smallest
> > example where operators are necessary?
>
> // Contains returns whether v is in the slice s.
> func Contains(type T)(s []T, v T) bool {
> for _, x := range s {
> if x == v {
> return true
> }
> }
> return false
> }

That's true. You can have this with interfaces as type constraints
with https://github.com/golang/go/issues/27481 however. That's the
minimally-necessary operator since comparing things is going to come
up more than anything else and == is the only operator not limited to
a small family of types.

There's still the problem with Equals vs ==, but that's a fundamental problem.

> > I'd be happy with generics if I needed to sometimes write a little bit
> > of code to do a few  things but didn't have to write a tremendous
> > amount of code to do most things. That seems like a good trade off,
> > even if it's not necessarily a popular one.
>
> But you can already do that, though, using interfaces.  Before we
> added sort.Slice, people complained quite a bit about sort.Interface,
> and that only required three lines.  Heck, people still complain that
> we have sort.Ints but not sort.Int32s.

In some cases like that. You can't have generic homogeneous type-safe
containers without some form of generics. That was the sort of thing I
was referring to: If I had to write a wrapper type with a Less method
to use a generic B-Tree that's not a big deal compared with writing an
entire B-Tree specialized to a certain type or having to wrap the
whole api to make it type safe.

Very few of the things I've wanted to do with generic require anything
other than at most == and convertibility. The lack of < would be
annoying at times but it's trivial to work around.

> > You could also write a min/max that operates on types with a Less
> > method, like you could under the various just-interfaces schemes.
> >
> > But you can't write one that works on both.
>
> Yes.  Though I'm not clear on whether people want that.  I think we
> need experience with real code here.
>
> If experience show us that this is important, my current guess is that
> the path forward here for Go is type adaptors, in which we say
> something like "if T implements contract C1, then you can
> automatically add this wrapper type and the wrapper type will
> implement contract C2."  But I think that is clearly a problem for
> later.

I forget where, but at some point I mentioned there could be equals(x,
y) and less(x, y) builtins that
- use x.Less(y) if it exists
- if not, use x < y
- if neither fail to compile.
(or Equals/== respectively)

Then you can use them in the contract and generic bodies. That would
only work with the contract proposal and not any of the interface
ones.

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

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

[jimmy frasche]

I meant without having to use a wrapper but still accepting all three.
I certainly agree that it not the Go way or the way to go.
On Thu, Sep 6, 2018 at 3:16 PM Axel Wagner
 wrote:
>
> 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 the methods - which is pretty much the only way to do it while 
> maintaining the property that only the owner of a type can define methods on 
> it.
>
> So, you can already do this. But it requires you to write it. Which is 
> boilerplate.
> (which I'm personally fine with, FTR :) )
>
>>
>>
>>
>> Even ignoring that, the contracts proposal doesn't let you write a
>> generic variadic min/max since there's no way to get the
>> smallest/largest value of a type so you can't write
>>
>> func min(type T ordered)(ts ...T) T {
>>   min := LargestPossible(T) // not possible
>>   for _, t := range {
>> if t < min {
>>   min = t
>> }
>>   }
>>   return min
>> }
>>
>> You could get around that with the signature (firstOne T, rest ...T)
>> but there's a larger point about the necessity of knowing numeric
>> limits and properties for writing that kind of generic code in there.
>>
>>
>> One way around the asymmetry between operators and methods that
>> doesn't introduce any issues like operator methods or any of that is
>> to have a package that defines types like
>>
>> package basic // not the best name
>>
>> type Int int
>>
>> type Slice(type T) []T
>>
>> // and so on for all the primitive and basic composite types
>>
>> and give all of those methods like Less and At. You'd have to do
>> int(min(basic.Int(x), basic.Int(y))) but at least you wouldn't have to
>> write the trivial wrapper methods. Not especially pretty.
>>
>> --
>> 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.

-- 
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] A thought on contracts

[jimmy frasche]

If the contract for a type is entirely inferred in order to know the
types it accepts you have to read all of its code, every line. The
contract let's you boil that down to the salient points so you can
read line a few lines instead of a few hundred or a few thousand.
On Thu, Sep 6, 2018 at 3:15 PM Thomas Wilde  wrote:
>
> Thanks for the response. I think the question then becomes: if the syntax in 
> contract bodies was an unrestricted Go block, then why do I need to repeat my 
> function's operations in a contract?
>
> If the syntax of contract bodies is free, then the Go compiler could easily 
> deduce all my constraints from a function body directly -- no need for a 
> separate contract.
>
> Thanks again and all the best,
> - Tom
>
> On Thu, Sep 6, 2018, 22:26 Ian Lance Taylor  wrote:
>>
>> On Tue, Sep 4, 2018 at 7:41 AM, thwd  wrote:
>> >
>> > From the draft proposal I gather two open questions:
>> >  - How free or restricted should contract bodies be?
>>
>> I believe it's useful to have contract bodies simply be arbitrary
>> function bodies, as the current design draft suggests.  This is
>> because I believe that is conceptually the simplest choice.  You don't
>> have to remember two different syntaxes, one for code and one for
>> contract bodies.  You just have to remember a single syntax, one you
>> must know in any case to write any Go code at all.
>>
>> >  - How many implicit constraints can be inferred from usage?
>>
>> As few as we can get away with.
>>
>>
>> > If too much syntax is allowed in contract bodies and no implicit 
>> > constraints
>> > are gathered:
>> > people will copy and paste function bodies into contracts to cover all
>> > constraints.
>>
>> People do suggest that that will happen but I think it is extremely
>> unlikely in practice.  It's obviously a terrible coding style, and
>> almost all generic functions have trivial contract requirements.
>>
>> 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.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Why can't we use < > for the Go generic parameters ?

[jimmy frasche]

I'd quite prefer [] over (). It would make F[t](v) distinct from
F(x)(y) even if it's not distinct from m[x](y).
On Thu, Sep 6, 2018 at 3:02 PM Ian Lance Taylor  wrote:
>
> On Thu, Sep 6, 2018 at 2:03 PM, jimmy frasche  wrote:
> >
> > Wouldn't there be an issue with fp := AFunc[int] ?
>
> I don't think so.  AFunc[int] would be parsed as an index operation,
> and after name lookup it would resolve into either an array lookup or
> a function instantiation, depending on the meaning of `int` in the
> current scope.  This is not very different from the way that t(v)
> resolves to either a function call or a type conversion after name
> lookup.  It's quite different from using <>, which has to be parsed
> quite differently depending on whether it is an instantiation or a
> comparison.
>
>
> > Though for that matter I wouldn't mind if the type part were repeated
> > for instantiations like AFunc[type int] or even AFunc(type int)
>
> That would be possible but seems unnecessary.  I personally would
> prefer to avoid it.
>
>
> > For that matter, always writing type would let you use < > since the
> > parser could plausibly enter a separate mode when it hit the < token
> > followed by type.
> >
> > Noisy but obvious at a glance what's happening.
>
> Yes, that is true except for the >> issue.
>
> 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.
For more options, visit https://groups.google.com/d/optout.

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

[jimmy frasche]

> 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 that everyone who knows Go will be able
> to do that.  But maybe that's just me.

For complicated contracts—and I mean even ones reduced by a tool to
their minimum—that turns into a puzzle solving contest. For ones that
aren't reduced, it's easy for them to be misleading, like: x % 5 == 0

I agree that it's something where eventually standardized practices
and tooling would fill in the gaps to the extent that these issues
would come up rarely. I'm mostly worried about the time between their
introduction and the stabilization because it will be measured in
years and remembered for longer.

> Something like the convert example in the design draft would still
> need contracts that are unlikely to be defined in the standard
> library.

In my draft proposal, I handled this like
  (type S, T interface{} | S(T))
which introduces two type parameters with no restrictions other than
that values of T must be convertible to S. It's treated specially but
it is somewhat special because it's a property between two types. It
was the only such property I found necessary.

> It's not necessary to support fields but I think it really is
> necessary to support operators.  I claim that, other than type safe
> data structures, the number one generic function that people want to
> write is Min (or Max).  I don't think we can plausible add a generics
> system to Go that doesn't permit writing a Min function.

Hypothetically, if Go introduced generics where you couldn't write
min/max but included min/max builtins, what's the next smallest
example where operators are necessary?

I'd argue that min and max are the only ones that would seriously be
impacted. Every other example is large enough that any boilerplate to
wrap methods would pale compared to the coding saved by being able to
safely reuse a large chunk of code.

I'd be happy with generics if I needed to sometimes write a little bit
of code to do a few  things but didn't have to write a tremendous
amount of code to do most things. That seems like a good trade off,
even if it's not necessarily a popular one.

But you can't really write a generic min/max with the contracts proposal.

You can write a min/max that operates on all the ordered types, sure.

(The one in the proposal has a bug because it accepts float types but
doesn't handle the special cases for floats. That can't be repaired
because while you could assert to float32 or float64 you couldn't
assert to type MyFloat float64. Though I'm sure there's some contract
where you can specify < but not floats.)

You could also write a min/max that operates on types with a Less
method, like you could under the various just-interfaces schemes.

But you can't write one that works on both.

If there were operator overloading any type could have < and you could
specify < in interfaces and then you could work on primitive and user
types equally.

But even then you still couldn't write a min/max that transparently
works on time.Time since it has Before not Less.

To unify those cases you need something like haskell-style typeclasses
where you can say this type satisfies this contract using these
methods/operators.


Even ignoring that, the contracts proposal doesn't let you write a
generic variadic min/max since there's no way to get the
smallest/largest value of a type so you can't write

func min(type T ordered)(ts ...T) T {
  min := LargestPossible(T) // not possible
  for _, t := range {
if t < min {
  min = t
}
  }
  return min
}

You could get around that with the signature (firstOne T, rest ...T)
but there's a larger point about the necessity of knowing numeric
limits and properties for writing that kind of generic code in there.


One way around the asymmetry between operators and methods that
doesn't introduce any issues like operator methods or any of that is
to have a package that defines types like

package basic // not the best name

type Int int

type Slice(type T) []T

// and so on for all the primitive and basic composite types

and give all of those methods like Less and At. You'd have to do
int(min(basic.Int(x), basic.Int(y))) but at least you wouldn't have to
write the trivial wrapper methods. Not especially pretty.

-- 
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] Why can't we use < > for the Go generic parameters ?

[jimmy frasche]

I meant that if the instantiation syntax is T. Though
it'd probably have to treat a >> token as two separate > in
declarations which is annoying.
On Thu, Sep 6, 2018 at 2:07 PM Jan Mercl <0xj...@gmail.com> wrote:
>
>
>
> On Thu, Sep 6, 2018, 23:03 jimmy frasche  wrote:
>>
>> Wouldn't there be an issue with fp := AFunc[int] ?
>>
>> Though for that matter I wouldn't mind if the type part were repeated
>> for instantiations like AFunc[type int] or even AFunc(type int)
>>
>> For that matter, always writing type would let you use < > since the
>> parser could plausibly enter a separate mode when it hit the < token
>> followed by type.
>
>
> The parser does not and not easily can know if 'a' in ' type name.
>
> --
>
> -j

-- 
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] Why can't we use < > for the Go generic parameters ?

[jimmy frasche]

Wouldn't there be an issue with fp := AFunc[int] ?

Though for that matter I wouldn't mind if the type part were repeated
for instantiations like AFunc[type int] or even AFunc(type int)

For that matter, always writing type would let you use < > since the
parser could plausibly enter a separate mode when it hit the < token
followed by type.

Noisy but obvious at a glance what's happening.
On Thu, Sep 6, 2018 at 1:43 PM Ian Lance Taylor  wrote:
>
> On Thu, Sep 6, 2018 at 1:38 PM, xingtao zhao  wrote:
> >
> > But we can still using [type T] instead.
>
> That is a very good point.  Thanks.  As far as I can see we could
> plausibly switch to square brackets if we prefer them.
>
> Ian
>
>
>
> > On Thursday, September 6, 2018 at 6:45:07 AM UTC-7, Ian Lance Taylor wrote:
> >>
> >> On Thu, Sep 6, 2018 at 5:28 AM,   wrote:
> >> >
> >> > Am Donnerstag, 6. September 2018 13:43:32 UTC+2 schrieb Christophe
> >> > Meessen:
> >> >>
> >> >> I understand your example, but it wouldn't be a problem anymore with a
> >> >> special character like a $ sign. D use the !.
> >> >
> >> >
> >> > Scala uses [ and ] instead of < and > to avoid the problem that < and >
> >> > mean
> >> > something different depending on the context.
> >>
> >> Note that simple [ and ] don't work in Go, as explained in the
> >> generics design draft.
> >>
> >> 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.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

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

[jimmy frasche]

Contracts are a brilliant solution to the problem on an intellectual
level. I really am impressed by how deftly they tackle the stated
problem. But I am concerned about their usability on the practical
level. The idea is simple but its user interface is not. I don't buy
the claim that it's okay because a priest-class will be the only ones
writing generic code. Everyone will still have to read it and deal
with it.

Scaling back the problem to simply not include operators and fields at
all looks like it eliminates so much of the complexity in the
implementation and its user interface. Any such limited solution
increases the boilerplate of using generics when operators and fields
come in to play, certainly, but I think the majority of use-cases for
generics are going to be data structures and algorithms more generally
expressible without operators anyway (few types have a < operator but
any type can have a Less method and without type classes in the
haskell/etc. there still isn't a way to handle both without accepting
a Less method and requiring a wrapper for types that have a <
operator).

Is it really *necessary* for generics to support operators and fields?
On Thu, Sep 6, 2018 at 9:54 AM Ian Lance Taylor  wrote:
>
> On Thu, Sep 6, 2018 at 8:20 AM,   wrote:
> >
> > As I wasn't happy with some aspects of it, I've rewritten my feedback on the
> > Go 2 Generics draft and deleted the original gist. Here's the link to the
> > new gist for anybody who's interested:
> > https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251
> >
> > This is still based on the type-class idea though I'm now proposing a
> > simplified contracts approach to go with it rather than trying to make
> > interfaces fit. It seems to deal easily now with all the examples in the
> > draft paper though no doubt there will be stuff that it can't do or that
> > I've overlooked.
>
> Thanks for writing this.  I never got around to reading the earlier
> feedback.  And thanks for working out the examples.
>
> Personally I think an important feature of the current design draft is
> that it adds relatively few new concepts to the language.  While
> concepts are of course a new feature, a contract looks like a
> function.  If you can read a function, you can read a contract.  You
> don't need to understand a new set of ideas to know what a contract
> is.  With your proposal, everybody has to learn a new set of
> predeclared identifiers.  You list 14 new ones, including $struct.  I
> count 39 existing predeclared identifiers, so this is a significant
> increase.  Also, of course, the new identifiers don't look like any
> existing ones, with the $, but perhaps that could be changed.  I would
> very much prefer to not add so many new names.
>
> If new features are added to the language, your approach may require
> new predeclared identifiers, whereas the contract approach will
> automatically adjust.
>
> It's worth noting that your suggestion is less powerful than the
> design draft, in that you can't express the notion of type parameter
> that must be a channel type or a slice type.  This may not matter very
> much, because the generic function can always write chan T or []T.
>
>
> > It looks to me as though, if it requires a contract at all, you might end 
> > up writing one from scratch for most generic functions/types you need. Even 
> > if the commoner ones could be included in a 'contracts' package in the 
> > standard library, you'd still need to import that package and then write 
> > stuff like 'contracts.Comparable' which is a bit verbose.
> >
> > Even if the present design prove workable, I think writing contracts may 
> > prove a bit of a black art and that, if things are at all complicated, some 
> > programmers may just give it up and embed the function's code in the 
> > contract which defeats the object of having them in the first place!
>
> I believe we can use tooling to make these operations easier.  For
> example, assuming we can make contracts work at all, it should be
> straightforward to write a tool that can minimize a contract given an
> existing contract definition, and therefore can produce a minimal
> contract for an existing function body.
>
> Note that while I think it's important that there be some way to
> express complex contracts, I think they will be used quite rarely.
>
>
> > The more I look at this, the more complicated it seems to get :(
>
> Yes.
>
> 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.
> For more options, visit https://groups.google.com/d/optout.

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

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

[jimmy frasche]

Is there a story for a module that changes domains, like when google
code shutdown or moving to a custom domain for vanity import paths?

Having directives to say "find earlier versions here" or "find later
versions" here seems like it would help downgrades/upgrades. If one of
those old domains stops existing entirely the chain would be broken,
certainly, but it still seems like it would be useful.

-- 
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] Library for implementing package matching similar to how "go build ./..." does it?

[jimmy frasche]

I have not used it personally but I believe this is what you are
looking for: https://godoc.org/golang.org/x/tools/go/buildutil#ExpandPatterns

On Mon, Oct 9, 2017 at 11:17 PM,   wrote:
> I'm looking for a library or function that implements the same logic that
> many of Go's CLI tools do:
>
> go build ./...
> go install ./...
>
> Where it will return a list of matched packages.
>
> I noticed that the code for this package matching is here:
> https://golang.org/src/cmd/go/internal/load/search.go
>
> I tried yanking it out, but there's additional internal dependencies that
> make it not as trivial as I would have liked. I'm wondering if anyone has
> already done this work or if there's support in the standard library
> somewhere.
>
> Thanks!
>
> Matt
>
> --
> 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.

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

Re: [go-nuts] Re: important

[jimmy frasche]

I didn't get that email either.

On Mon, Oct 9, 2017 at 9:51 AM, Jan Mercl <0xj...@gmail.com> wrote:
>
> On Mon, Oct 9, 2017 at 6:43 PM Ian Lance Taylor  wrote:
>
>> Didn't I answer this question already?
>
> Obviously you did, I can see your answer in the web interface, but if the OP
> is using only the mail for communicating with the group, as I do, I must say
> that your answer never made it to my inbox and that's probably why the OP is
> asking again.
>
> --
>
> -j
>
> --
> 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.

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

Re: [go-nuts] Re: Proposal: Just Use GitHub

[jimmy frasche]

It's easy to focus on the darker turns that thread took, but it also
led to a lot of good discussion.

It got work restarted on https://github.com/golang/go/issues/18517 and
led to the following issues being filed:
- https://github.com/golang/go/issues/21980
- https://github.com/golang/go/issues/21983
- https://github.com/golang/go/issues/22002
- https://github.com/golang/go/issues/22007

That may not have been the goal of the thread per se, but I'd still
count them as a positive outcome.

On Sun, Sep 24, 2017 at 3:04 AM, Henrik Johansson  wrote:
>  I am sorry but this type of straw man is not what Nate and others are
> arguing for.
> Never has anyone suggested we sacrifice quality for quantity but rather that
> more better than less to turn the old adage around.
>
> If code review can be done efficiently enough and by enough people then more
> contributors is better.
> I think a move like this would initially hurt the process but over time
> improve it since more contributors would also lead to more reviewers.
>
> My 2¢
>
>
> sön 24 sep. 2017 kl 09:01 skrev Nigel Vickers :
>>
>>
>>
>> On Thursday, 21 September 2017 04:27:19 UTC+2, Nate Finch wrote:
>>>
>>> https://github.com/golang/go/issues/21956
>>>
>>> Wherein I suggest that not using GitHub for PRs and Reviews for the Go
>>> Project itself is hurting the language and the community.
>>
>>
>> I have been lurking on this discussion until now. I do not "like" the
>> nature or tone that this discussion has taken.  I am not a contributor to Go
>> but have experience with a large Open Source Project. I use Go daily.  All
>> Communities have problems attracting contributors, but the problem is not
>> just "Quantity" it is also "Quality". PRs cannot be just accepted; they have
>> to be "Reviewed". I think the "worst" case I have encountered involved 6
>> lines of PHP code that "ping ponged" 26 times before a "programmer with a
>> bad case of agenda" accepted that his code wasn't doing what he thought.
>> Reviewers' working in such environments are rare and their feelings on the
>> matter must be respected. GitHubs' review procedure does not have the depth
>> or history that is necessary.
>>
>> Suggestions that the "Leaders of the Project" are following some hidden
>> "Google Agenda" is unacceptable. You should be taking the state of Githubs'
>> review to GitHub and not proposing to "Hamstring" the Go reviewers.
>>
>> imho.
>>
>>
>> --
>> 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.
>
> --
> 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.

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

Re: [go-nuts] Re: Go 1.9 is released

[jimmy frasche]

Thanks for all the great work—lots of exciting changes in this release!

On Thu, Aug 24, 2017 at 3:52 PM, Nathan Kerr  wrote:
> Congrats!
>
> I updated my Go Release Timeline and When Should You Upgrade Go? pages.
>
> On Friday, August 25, 2017 at 12:44:25 AM UTC+2, Chris Broadfoot wrote:
>>
>> Hello gophers,
>>
>> We just released Go 1.9.
>>
>> You can read the announcement blog post here:
>>   https://blog.golang.org/go1.9
>>
>> You can download binary and source distributions from our download page:
>>   https://golang.org/dl/
>>
>> To compile from source using a Git checkout, update to the release with
>> "git checkout go1.9" and build as usual.
>>
>> To find out what has changed, read the release notes:
>>   https://golang.org/doc/go1.9
>>
>> Thanks to everyone who contributed to the release.
>>
>> Chris
>
> --
> 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.

-- 
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] multiply and divide

[jimmy frasche]

There's https://github.com/golang/go/issues/19623 for making int
arbitrary precision in Go2 (yes, please) there could also be an
arbitrary precision float to go with float32/float64 :D

On Sat, Aug 19, 2017 at 8:04 AM, Michael Jones  wrote:
> I would REALLY like to see big types as normal declarations and syntax. The
> SSA framework seems suitable to automatically manage the temporaries.
>
> On Sat, Aug 19, 2017 at 7:14 AM, roger peppe  wrote:
>>
>> Constructive reals in Go, anyone? :-)
>>
>> On 18 Aug 2017 17:50, "Michael Jones"  wrote:
>>>
>>> Here is a minor musing from something that came up yesterday.
>>>
>>> Sometimes we see a real number expression as simple as...
>>>
>>>   x*y/z
>>>
>>> ...and knowing from basic algebra that...
>>>
>>> (x*y)/z == x*(y/z)
>>>
>>> ...we might not expect much difference between the two in our code. Alas,
>>> computer floating point does not involve real numbers, rather it uses an
>>> approximation of them. If you will copy https://play.golang.org/p/IlDxtvx7IY
>>> to your computer, build and run it, (too much CPU for the playground) you'll
>>> find that the order makes a difference. Or, you can just remember this
>>> phrase, "multiply first, then divide."
>>>
>>> --
>>> Michael T. Jones
>>> michael.jo...@gmail.com
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Michael T. Jones
> michael.jo...@gmail.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

[jimmy frasche]

I never return a broken value with an error because there are
occasions where returning both a value and an error make sense, such
as a partial read. More than anything else, I'd rather make it clear
that this is not one of those cases so I don't confuse myself later
when I'm trying to track down a bug.

On Fri, Mar 31, 2017 at 5:02 PM, 'Axel Wagner' via golang-nuts
 wrote:
>
>
> On Sat, Apr 1, 2017 at 1:50 AM, Dave Cheney  wrote:
>>
>>
>>
>> On 1 Apr 2017, at 10:41, Axel Wagner 
>> wrote:
>>
>> So… Given that I'm not talking about modifying any contract - see a) in my
>> previous message - but just making an effort that I'm not contractual bound
>> by, I am not sure how I am supposed to read this. Is this an argument for
>> not being helpful? Because I don't quite see how your point invalidates
>> that. Or is it an argument for being hurtful? Which I also don't really see,
>> as I'm not talking about any change in contract.
>>
>> Like, I legit starting to doubt my sanity here; I don't see how I can
>> actually be any clearer about how I do not intend to change anything about
>> the "if a non-nil error is returned, assume the returns are invalid" rule.
>> The question is "how is it hurtful, if I then also add an extra layer of
>> defense against people violating that contract"?
>>
>>
>> But why? Why encourage people to be reckless. IMO this is difference
>> between map ordering during iteration being undefined, which it is, rather
>> than guaranteed to be random, which is not.
>
>
> Great point. Why does gc implement it that way, then? And does it hurt, that
> gc implement it that way? The contract does not contain anything about the
> iteration order, so why did we add that code and CPU time to explicitly
> randomize it, instead of just letting buggy code be buggy and blow up at
> some point with hard to debug errors? This seems to be essentially the
> argument you are making, so why does it, seemingly, not apply to randomized
> map iteration in gc?
>
>>
>>
>> Both are contracts with the same result to the casual user -- map
>> iteration is unpredictable, but by not guaranteeing that the order will be
>> random, it prevents people relying on the side effect.
>>
>> This is the argument I'm making now, yes, you could go to effort to make
>> sure that some of the values you return are nil so that they explode as soon
>> as someone forgets to check an error, but you probably shouldn't because
>>
>> A, this is providing a stronger contract than necessary.
>
>
> No, it is not. The contract is the same. I'm sorry to be a stickler here,
> but I really don't see why this point is so elusive. I am not suggesting
> adding a "if an error is returned, the other return values will have their
> zero value" to my godoc.
>
>>
>> B, it encourages people to be clever and try to avoid the error checking
>> idiom.
>
>
> I legit don't see how, given that this is not a rule. I also don't do it
> with any kind of strictness that would allow people to rely on it.
>
>>
>> C, doesn't work for all return values, only the pointer shaped ones.
>
>
> I disagree. An empty string or a 0 or whatever is *still* a much more
> telling symptom to debug than *some* string/integer/whatever, especially if
> it's an invalid value (and if it isn't; why is would we even talk about it).
>
> But anyway, yes, I mostly do this with pointers, but *so what*? Why throw
> the baby out with the bathwater? Again, this is not part of any API. This is
> not an all or nothing thing. This is a safety net for people coding bugs and
> it's totally fine if it is there sometimes and not there at other times (and
> you even argue yourself that it shouldn't, to "keep people on their toes").
>
>>
>>
>>
>>
>> Are you trying to say that I'm training them to not adhere to the
>> contract? Because I don't see how; it's blowing up either way, just, in one
>> case the blowup might be easier to detect and debug.
>>
>> I respect your opinion and I do agree, but we just seem to be talking
>> about different things… anyway. Sleep, for now.
>>
>> On Sat, Apr 1, 2017 at 1:09 AM, Dave Cheney  wrote:
>>>
>>> I think the simpler contract is to give no guarantee whatsoever of the
>>> state of the other return values in the presence of an error.
>>>
>>> It's a simple, clear, and most importantly consistent contact.
>>>
>>> To guarenteed that in the presence of an error the values that can be
>>> respresented by nil _will_ be nil is less consistent, and more importantly
>>> encourages people to not check error by substituting their own ad-hoc tests
>>> like testing if a return value is nil, implying an error.
>>>
>>> --
>>> 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 

Re: [go-nuts] Re: Gracefully Shutdown File Server

[jimmy frasche]

Maybe go run is eating the signal? Does it still misbehave with go build?

On Fri, Mar 10, 2017 at 12:18 PM, Bruno Albuquerque  wrote:
> I am not very familiar with the shutdown process yet (I did not try to use
> it anywhere), but the documentation seems to imply that what you expected to
> happen is what should happen. So if the download is being interrupted, I
> guess that is a bug.
>
>
> On Fri, Mar 10, 2017 at 11:33 AM Andrew  wrote:
>>
>> Suppose I have a new folder with two files, main.go(code from the link)
>> and myfile.iso(large file).
>>
>> After "go run main.go" from the console, open browser and type
>> "localhost:8080/myfile.iso" to download the file.
>> Back to the console and Ctrl+c to shut down the server when the file is
>> downloading.
>>
>> The server will stop immediately and the file downloading process failed.
>>
>> Is this the correct behavior of Server.Shutdown?
>>
>> I think the server should wait for the file downloading process to finish
>> or timeout after 5 seconds instead of terminate immediately, right?
>>
>>
>> --
>> 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.
>
> --
> 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.

-- 
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 can print MAP data without randomized?

[jimmy frasche]

You can create a slice of the keys in any order you want and use that
to control the iteration. Map iteration is always randomized.

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

On Thu, Feb 9, 2017 at 1:08 PM,   wrote:
> hi
> How can print MAP data without randomized?
>
> --
> 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.

-- 
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] Unary +

[jimmy frasche]

Even if you disagree with Iverson check out
https://en.wikipedia.org/wiki/Iverson_bracket notation. That's good
stuff. It should be the standard notation.


On Sat, Aug 20, 2016 at 1:24 PM, Bakul Shah  wrote:
> Thank goodness for loony ideas, eh? I learned a lot from Iverson’s writings
> and APL and its descendents. It is worth revisiting his writings (just like
> Dikjstra’s) from time to time. Array programming should be much more
> aprpeciated these days when many-core processors are becoming more and cloud
> based services essentially stand up an array of identical servers — and we
> have to use clumsy notation for all this. At any rate mathematics doesn’t
> exactly have a completely logical system of symbols.
>
> Incidentally the only meaningful use of unary +  I’ve seen is in K (another
> array programming language), where it stands for the “transpose” function,
> where the first two axes of an array are swapped.
>
>   (1 2;3 4) // outputs as:
> (1 2
>  3 4)
>   +(1 2;3 4)
> (1 3
>  2 4)
>
>
> Another aside: Go’s treatment of - for constants is a bit weird. I’ll
> explain with an example from Gambit Scheme, which has the correct behavior:
>
>> (/ 1.0 0.0)
> +inf.0
>> (/ 1.0 -0.0)
> -inf.0
>
>
> As you can see -0.0 does have a meaning different from +0.0.
>
> In Go there are two issues:
> The compiler refuses to divide by the constant 0.0 — This operation has a
> well defined meaning but the compiler thinks it knows best (this behavior is
> documented in the spec, which is good, but I don’t see the rationale for
> this behavior). So one has to use a variable to test this … where we run
> into the second problem: -0.0 is treated the same as +0.0:
>
> x := -0.0
> fmt.Println(1.0/x)
>
>
> This prints +Inf, when it should be printing -Inf. One has to explicitly
> negate x as in
>
> fmt.Println(1.0/-x)
>
>
> Aside #3: Lucio, knowledge of K and its friendier version Q (used in KDB+)
> can be very rewarding! They are used in quantitative finance (along with
> python, matlab, ocaml etc). Though the number of available jobs are perhaps
> small (also because one APL/J/K/Q programmer can cause a lot of havoc in
> just one line of code!)
>
> On Aug 20, 2016, at 5:28 AM, Michael Jones  wrote:
>
> I took Thomas’s “loony-land” comment as jest.
>
> Presumably we all study the Turing Award lectures, each being the computer
> science community’s way of passing a life’s celebrated contributions to the
> future. In Dr. Iverson’s Turing Award lecture, “Notation as a Tool of
> Thought,” he explores the link between expression of ideas and the power to
> create and advance ideas. Essentially, that “language shapes thought,” one
> of the beliefs I hold. His use of minus and negative there are not the only
> “loony” (perhaps meaning “other than ordinary”) ideas in what remains to
> this day an intellectual treasure.
>
> I have Iverson’s high-school textbook which uses the notation. You see the
> notation it as APL, but in fact it was created as a way to describe a
> computer architecture (the IBM 360 then in development) in a formalism that
> allowed proofs of operation and implementation. I studied those books too.
> It is not so uncommon that an at first bewildering notation can come to feel
> a comfortable home. This is true of music, mathematics, emacs, and much
> more. Rob Pike’s Ivy is APL themed if you want to explore that. The latest
> descendent of APL is “J,” itself a descendent of “Dictionary APL” which was
> Iverson’s effort to use ordinary notation to lower the initial threshold for
> new programmers.
>
> Michael
>
> From: Lucio 
> Date: Friday, August 19, 2016 at 10:23 PM
> To: golang-nuts 
> Cc: Michael Jones ,
> , 
> Subject: Re: [go-nuts] Unary +
>
>
>
>
> On Saturday, 20 August 2016 02:29:17 UTC+2, Thomas Bushnell, BSG wrote:
>
> With all due respected to the illustrious Dr. Iverson, he was in loony-land
> with his two versions of minus.
>
>
>
> I take exception to the "loony-land" qualification of Dr Iverson's raised
> minus. I think it was immensely appropriate and sadly forgotten that APL
> introduced the brilliant idea of discarding operator precedence in favour of
> making functions themselves operators with NO associated precedence. The use
> of a raised minus to eliminate confusion was a sensible one, one Michael
> Jones further justifies in its use in teaching Algebra (I still smart when I
> remember my confusion in Algebra classes after the teacher dropped all minus
> and plus signs and the parentheses she'd used until then!).
>
> Even sadder, I find the disappearance of RPN from hand-held calculators, for
> which I hold HP almost entirely responsible.
>
> That APL is still available in some form or other I find emotionally,but
> sadly not economically, rewarding. My short liaison with the language has
> given me a 

Re: [go-nuts] Re: os.exec.Command and non-nil return status

[jimmy frasche]

Sorry for bumping an oldish thread, but I just ran into this trying to
propagate an exit code.

I didn't find anything searching that was sufficiently
platform-independent, but a little spelunking into the stdlib source
bore fruit, so I thought I'd share my solution.

If you have an *exec.ExitError it embeds an *os.ProcessState.

*os.ProcessState's Sys method returns an interface{} containing the a
platform specific type from the syscall package.

But all the platform specific types have a method ExitStatus() int.
(Even nacl and Plan 9, which fake it).

So, given an *exec.ExitError x, to get the exit code you just need to do:

exitCode := x.Sys().(interface{
  ExitStatus() int
}).ExitStatus()

I suppose it wouldn't hurt to check that type assertion and return -1
if it fails, though I imagine if that ever happened it would be a bug
in a new port.


On Thu, Jun 2, 2016 at 4:14 AM, Konstantin Khomoutov
 wrote:
> On Wed, 1 Jun 2016 23:56:43 +0300
> Janne Snabb  wrote:
>
>> You should check if the type of err is *exec.ExitError and in that
>> case consider it just as non-zero exit value from the process.
>>
>> The following snippet from
>> https://golang.org/src/os/exec/exec_test.go#L123 clarifies it:
>>
>> func TestExitStatus(t *testing.T) {
>>   // Test that exit values are returned correctly
>>   cmd := helperCommand(t, "exit", "42")
>>   err := cmd.Run()
>>   want := "exit status 42"
>>
>>   if werr, ok := err.(*exec.ExitError); ok {
>>   if s := werr.Error(); s != want {
>>   t.Errorf("from exit 42 got exit %q, want %q",
>> s, want) }
>>   } else {
>>   t.Fatalf("expected *exec.ExitError from exit 42; got %
>> T: %v", err, err) }
>> }
>
> I'd warn the OP to take this snippet with a hefty grain of salt: while
> it's perfectly reasonable for the test suite of an stdlib package to
> test the output of os/exec.ExitError.Error(), 3rd-party code must not
> rely on the output of the Error() methods of error values of any type to
> be predictable and stable -- at least until there's absolutely no
> other way to get onto error's details.
>
> That is, the OP should consider writing a helper function to test the
> error returned by os/exec.Cmd.Run() et al to check whether the exit
> status is non-zero and discard the error value if so.
>
> An example:
>
> 8<
> package main
>
> import (
> "os/exec"
> "testing"
> )
>
> func maybeIgnore(err error) error {
> if _, ok := err.(*exec.ExitError); ok {
> return nil
> }
> return err
> }
>
> func TestExitCode(t *testing.T) {
> cmd := exec.Command("/bin/sh", "-c", "exit 42")
> err := maybeIgnore(cmd.Run())
> if err != nil {
> t.Error("Expected nil error, got: %#v", err)
> }
> cmd = exec.Command("./does not exist, really")
> err = maybeIgnore(cmd.Run())
> if err == nil {
> t.Error("Expected non-nil error, got nil")
> }
> }
> 8<
>
> (Save as  "whatever_test.go" and run `go test`.)
>
> --
> 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.

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