Re: [go-nuts] [Generics] Feedback on updated draft

[Aleksey Tulinov]

I'm not sure if i understood everything correctly.

type structField(type T) struct {
a int
x T
}

But this is a generic type, not a constraint for a type, isn't it?
Constraint is this:

type Custom interface{
type int, float64, uint64
}

type structField(type T Custom) interface {
  type struct { a int; x T },
struct { b int; x T },
struct { c int; x T }
}

What am I missing? And I think it rather well highlights what I am
talking about. Consider the following pseudocode:

type ConstraintIWant interface {
  ConstraintA || ConstraintB // i don't care which one, either is fine
}

Maybe i'm looking in the wrong place, but i think that to do this I
have to extract `CommonPart` (`Custom`) from `ConstraintA` and
`ConstraintB`, add `CommonPart` back to both constraints so they
aren't broken and then request `CommonPart` in `ConstraintIWant`.

This is Java-style inheritance. It isn't bad, but i think that
C++-style composition is somehow more in the spirit of Go. Strictly
personal opinion of course. Older proposal described constraints as
expressions, so to me it appears superior because I could potentially
write an expression I want without asking for more features to be
added into the compiler.

Although i'm no longer sure if I understand what Go generics are
supposed to do. You have the point that it's probably for a specific
purpose, generic types something something, i don't know, but it
probably isn't supposed to do what C++ concepts can do. Maybe i'm just
spoiled.

If this gets us to where we want to be - that's great, I'm happy if
you're happy. It just doesn't feel quite right and i feel like this
proposal could benefit from discussion on composition and stuff like
that.

чт, 23 июл. 2020 г. в 06:29, :
>
> Hey! I would like to join the discussion and add my 5 cents here, since I 
> have been criticizing the contracts draft and I would like to show what were 
> my points in order to support the current design draft.
>
>
> I believe the original problem for the generics is to allow the same function 
> to work on values of different types. So that You do not need to write 
> something like AddInt, AddInt32, AddInt64 and so on. This is an example of 
> situation when we would like to write something like Add(T) and make that T 
> to be one of the list: int, int32, int64 - all of the types what we have the 
> Add function defined for.
>
>
> In this case Add(T) acts much like an expression evaluating to a different 
> function depending on the T.
>
>
> This can be called “parametrization by type” or “type parametrization” and I 
> believe it is an exceptionally simple and straightforward way to do it.
>
>
> Let me say a bit more about problems where need of contracts arise.
>
>
> When we are writing in a context of type-parametrized function something like:
>
>
> var a []T = []int{1, 2, 4}
> a[2] = 3
>
>
> It is okay to write []T[2] = T (assign a value of type T to an element of 
> array of type T by index 2) and we do not need to care what is T.
>
>
> But when we change a bit:
>
>
> var a T = []int{1, 2, 4}
> a[2] = 3
>
>
> It becomes hard to judge whether we are allowed to write T[2] = 3 (assign 3 
> to an element of type T by index 2). In order it to work, we need to state 
> somehow [2] is allowed for T. There are a few ways to achieve it and the 
> first one is the contracts:
>
>
> type T interface{
> require(a, b) {
> a[2] = b
> }
> }
>
>
> Okay, now, let’s say, we are allowed to write T[2] = 3. But let’s try a 
> harder example
>
>
> var a T = []int{1, 2, 4}
> a[2] = 3
> a = append(a, 4)
>
>
> This will not work with the previously defined contract T, since a 
> map[int]int value also fits it.
>
>
> Should we write something like this:
>
>
> type T interface{
> require(a, b) {
> a[2] = b
> a = append(a, b)
> }
> }
>
>
> But what is the point in such syntax? How the compiler could guess and how 
> exactly it should work? What if we write random garbage in the require body, 
> will it allow us to write it right in the code without any checks?
>
>
> type T interface{
> require(a, b) {
> a *@#&@#$= b
> }
> }
>
> var a T *@#&@#$= b
>
>
> Of course, we can restrict it to allow using only operators like [], == and 
> so on, still how can we distinguish between a map and an array?
>
>
> type T interface{
> require(a, b, i) {
> a[:] // only arrays and slices have this operator
> i++ // i is an integer
> a[i] = b // b is an element of array a
> }
> }
>
>
> Is this enough to define what we want? Such a contract would also require the 
> append builtin to be changed, but I believe it will only clutter up the 
> implementation with unnecessary type assertions.
>
>
> These “requires” act very much like predicates and are just tricky way to 
> “shortly” define a list of types. That is to say, a++ means any type having a 
> ++ operator defined for it no matter how exactly (which is a problem itself). 
> Anyway, 

[go-nuts] Generics syntax: declaring a generic type

[burak serdar]

This is a suggestion about the declaration of a generic type. There is
something unnatural in the syntax:

type SomeIntf(type T) interface {
 ...
}

type SomeStruct(type T) struct {
...
}

func SomeFunc(type T)(...) {...}


In all of the above, the names SomeIntf, SomeStruct, and SomeFunc are
being defined as generic types. However, all the regular types are
defined using the pattern:

"type" typeName typeDefinition

So why not:

type SomeIntf interface(T) {
  ...
}

type SomeStruct struct(T) {
...
}

func(T) SomeFunc(...) {...}

-- 
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/CAMV2RqqDiaKjzisPp-Z2GTT4uynWV%2Br25%2Bdv184HW6cHxwronA%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[Steven Blenkinsop]

On Wed, Jul 22, 2020 at 8:02 PM, Russ Cox  wrote:

> So it sounds like everyone is in favor of the entire generics proposal and
> all the semantics, and all we have left to hammer out is the bracket
> characters? Do I have that right?
>
> Best,
> Russ
>

I think this thread is specifically about the delimiters (first post is
about using square brackets instead of parentheses), but yeah, seems about
right.

I sort of wish interfaces allowed you to specify a receiver type rather
than requiring reflexive application (even where supported by syntax
sugar). Essentially:

type CustomOrdered interface(R) {
Less(other R) bool
}

instead of

type CustomOrdered[type T] interface {
Less(other T) bool
}

However, this is similar to type lists in interfaces in that it would make
the interface only usable as a constraint, since otherwise the receiver
type isn't known at compile time. The current design sidesteps this by
requiring you to specify a specific type argument in order to use the
interface as a type, even if the resulting interface type isn't terribly
useful. Reflexive application only works when using the interface as a
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/CANjmGJvZ3zbptYmFep%3Dex9uRbFEo16qvuUH_jL8aUqOLcA1mAA%40mail.gmail.com.

Re: [go-nuts] [Generics] Feedback on updated draft

[lx . gulak]

Hey! I would like to join the discussion and add my 5 cents here, since I 
have been criticizing the contracts draft and I would like to show what 
were my points in order to support the current design draft.


I believe the original problem for the generics is to allow the same 
function to work on values of different types. So that You do not need to 
write something like AddInt, AddInt32, AddInt64 and so on. This is an 
example of situation when we would like to write something like Add(T) and 
make that T to be one of the list: int, int32, int64 - all of the types 
what we have the Add function defined for.


In this case Add(T) acts much like an expression evaluating to a different 
function depending on the T.


This can be called “parametrization by type” or “type parametrization” and 
I believe it is an exceptionally simple and straightforward way to do it.


Let me say a bit more about problems where need of contracts arise.


When we are writing in a context of type-parametrized function something 
like:


var a []T = []int{1, 2, 4}
a[2] = 3


It is okay to write []T[2] = T (assign a value of type T to an element of 
array of type T by index 2) and we do not need to care what is T.


But when we change a bit:


var a T = []int{1, 2, 4}
a[2] = 3


It becomes hard to judge whether we are allowed to write T[2] = 3 (assign 3 
to an element of type T by index 2). In order it to work, we need to state 
somehow [2] is allowed for T. There are a few ways to achieve it and the 
first one is the contracts:


type T interface{
require(a, b) {
a[2] = b
}}


Okay, now, let’s say, we are allowed to write T[2] = 3. But let’s try a 
harder example


var a T = []int{1, 2, 4}
a[2] = 3
a = append(a, 4)


This will not work with the previously defined contract T, since a 
map[int]int value also fits it.


Should we write something like this:


type T interface{
require(a, b) {
a[2] = b
a = append(a, b)
}}


But what is the point in such syntax? How the compiler could guess and how 
exactly it should work? What if we write random garbage in the require body, 
will it allow us to write it right in the code without any checks?


type T interface{
require(a, b) {
a *@#&@#$= b
}}
var a T *@#&@#$= b


Of course, we can restrict it to allow using only operators like [], == and 
so on, still how can we distinguish between a map and an array?


type T interface{
require(a, b, i) {
a[:] // only arrays and slices have this operator
i++ // i is an integer
a[i] = b // b is an element of array a
}}


Is this enough to define what we want? Such a contract would also require 
the append builtin to be changed, but I believe it will only clutter up the 
implementation with unnecessary type assertions.


These “requires” act very much like predicates and are just tricky way to 
“shortly” define a list of types. That is to say, a++ means any type having 
a ++ operator defined for it no matter how exactly (which is a problem 
itself). Anyway, it is very easy, to define such a contract with a list, 
which is the second way of saying T[2] = 3 statement is allowed:


type Incrementable interface{
type int, int32, ...}


Let’s get to Your example:


type structField interface {
  type struct { a int; x int },
struct { b int; x float64 },
struct { c int; x uint64 }}


It is clearly visible, that we need to parametrize by a single field type:


type Custom interface{
type int, float64, uint64}
type structField(type T Custom) interface {
  type struct { a int; x T },
struct { b int; x T },
struct { c int; x T }}


Depending on the context, we also can write it like this:


type structField(type T Incrementable) interface {
  type struct { a int; x T },
struct { b int; x T },
struct { c int; x T }}


And even further, we can consider such a change:


type structField(type T) struct {
a int
x T}


And such a refactoring becomes now a pattern.


Instead of writing


type T interface{
type map[int]string, map[int]bool}


We almost always should write:


type Z(type T) map[int]T


It is a way stricter way of defining not only “contracts” but also types 
allowing us to perform such things like appending elements to arrays, 
taking element of a map by its key, accessing a struct field and much more 
while remaining generic enough.


Thanks for the attention, I hope it helps.

-- 
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/164a69fd-50f3-4a0e-ad9d-5e243c3b007bo%40googlegroups.com.

[go-nuts] Fuzzing design doc from Go team

[Liam]

The Go team has released a design doc for a Fuzzing API.
  https://golang.org/s/draft-fuzzing-design

The original proposal is
  https://github.com/golang/go/issues/19109

Discussion is on Reddit, which I don't wish to use for technical feedback 
or debate.

I haven't seen an announcement; I noticed because a new issue was briefly 
open.
  https://github.com/golang/go/issues/40307

-- 
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/185f4bc0-e2c3-493b-8672-6764a24758d1o%40googlegroups.com.

Re: [go-nuts] [Generics] Feedback on updated draft

[Ian Lance Taylor]

On Wed, Jul 22, 2020 at 5:12 PM Aleksey Tulinov
 wrote:
>
> Hmm. I must have read the previous version, but it probably was some
> time ago. I have to say that i like the previous version more than the
> current one.
>
> I definitely don't like this:
>
> type structField interface {
>   type struct { a int; x int },
> struct { b int; x float64 },
> struct { c int; x uint64 }
> }
>
> If this is more readable than `require (a) { a.x++ }`, then i don't
> even know what to say. My understanding of readability must be very
> different.

Agreed.  But this is an extreme special case, only included in the
design draft as an example.  Personally I think it would be fine if
generics in Go had no way to say "the type must be a struct with a
numeric field x."



> However the real point is not in a syntax, but in decoupling require
> expression from constraint, so it's more generic and extensibleso to
> speak. So maybe:
>
> type IncrementX interface {
>   require (a) {
> evaluates(a.x) && evaluates(a.x++)
>// where evaluates() is defined elsewhere like `require (x) { x }`
>   }
> }
>
> And type requirement could be `require { type int, int8, int16, int32,
> int64 }`? Even though this still doesn't look right to me.

The more language constructs we add, the harder the language is to
understand.  The current design draft adds two language constructs:
type parameters and type lists in interfaces.  It adds one new name:
comparable.  Every new name, like "require" or "evaluates", carries a
heavy cost in comprehensibility, as it becomes something that every
user of Go needs to learn.



> >The objection you mention to the approach used in the current draft is 
> >something like: what if Go changes such that operators (other than == and 
> >!=) apply to types other than primitive types?  But we're in charge of Go;
>
> Yeah, sure. But there will be some code out there that depends on
> existing constraints. If I understand this correctly, `Ordered` in the
> current proposal does not define constraint that require operator `<`,
> it defines a specific set of types and exploits a side effect that
> operator '<' can be applied to every type from this set. This
> introduces other side effects, for example, operator `==` is also
> defined for all those types, so at least it defines what it wasn't
> supposed to define.
>
> I'm not sure if this is OK or not, just saying, but if Go somehow
> changes "interface" of types under `Ordered`, then I think `Ordered`
> will indirectly change its meaning because it will inherit those
> changes even if they are unrelated to operator `<` or ordering in
> general. Just wanted to point out that side effects work both ways,
> and if those side effects are already exploited in existing Go code,
> then it might be harder to change other parts that at first sight are
> completely unrelated to what is being changed. Hope this helps.

All true.  The question is whether it is likely to lead to problems.

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/CAOyqgcUoo42KdGYjOKRwZRtGtsYAdPE-GiLQyG-UGsbh8KwFcg%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[Kent Sandvik]

[ ] is nice. Nim also uses [ ] for generics. --Kent

On Wed, Jul 22, 2020 at 4:41 PM Denis Cheremisov 
wrote:

> Lesser and greater signs never were a good choice. They were chosen
> because of C syntax restrictions. Go creators would do *slice[T]* (or may
> be just *[T]*), *map[K,V]*,* chan[T]*, etc if they had generics in mind.
> Because, if you have managed not to notice it, Go barely inherited anything
> from C. Know why? Because C is full of unfortunate decisions. Some people
> love it because this is their first relatively low level language and they
> like the power. Me, who wrote assembler before C, have never been impressed
> with it: its syntax is not particularly pleasant to read and I rather felt
> the lack of power with it. It is not only hard to read, it is just plain
> weird. Consider this:
>
> a * b;
>
> What is this? May be an expression? Or a declaration, pointer a of type b?
>
> So, please stop using languages with syntax inherited from C as a
> benchmark. The C is a result of the lack of planning, a chaotic
> development. And this usage of comparison operators as brackets is an
> unfortunate combination of circumstances.
> Luckily, there was a planning in Go, with some initial limitations which
> causes a bit of pain nowdays, still much better than C and even more so
> than C++. I am really glad they don't consider these < monstrosities: I
> tried Scala and as much as I dislike the language in general their []
> things for generic parameters left very good impression. I really like they
> borrowed the idea.
>
> четверг, 23 июля 2020 г. в 00:22:26 UTC+3, sah...@naman.ms:
>
>> With angled brackets, do we really need the colon or dot on both sides?
>> Wouldn't it be enough to just have it on the left to eliminate the parse
>> time ambiguities?  Like f<:int> or f<.int>?
>>
>> On Wed, 22 Jul 2020, 22:46 Евгений Кошевой,  wrote:
>>
>>> Maybe something like this:
>>> using <.Type.>
>>> func f(T<.int.>)
>>> struct{ T<.int.> }
>>> interface{ T<.int.> }
>>> []T<.int.>{}
>>>
>>> среда, 22 июля 2020 г. в 01:12:32 UTC+3, Steven Blenkinsop:
>>>
 On Tue, Jul 21, 2020 at 3:12 PM, Michal Strba 
 wrote:

> I'd say a dot is necessary when instantiating a function call but
> unnecessary when instantiating a type because it's always syntactically
> clear when a type is required.
>

 That's not true in Go. Conversions look like function calls:

   y := f(x)

 could be a conversion or a function call, depending on whether f is a
 function or a type. If you need to use type parameters on f, the same
 parsing problems present themselves whether it's a parameterized type or a
 type parametric function.

> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/a6a400ee-b9e2-4f30-a82d-a39ad8f5aaafn%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/f5e27f11-3dc4-4caa-adc4-4f4619a50cfcn%40googlegroups.com
> 
> .
>

-- 
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/CAHC_roEWOD870YOVvXZ54r-CY4FP4n-UhQXiCVJ2UjL-%2B0ZL-g%40mail.gmail.com.

[go-nuts] Generic symbol metaproposal

[Michael Jones]

One interesting fact of go is that semicolons are required at the end of
statements. A fact forgotten perhaps because of the automatic ‘we’ll insert
one for you’ process. This duality, required but auto-supplied in nearly
every case is a delightful outcome.

Another delight is the uppercase signal for external.

Maybe the “how to signal it” aspect of type instantiation could look to
these approaches as well—make the automatic understanding so magical that
the complete specification is unnecessary in most all cases, or the
signaling so intrinsic to the variables that no identification Symbol or
BracketedPair is necessary.

Do I have a perfect example? No. Imperfect, sure.

Choice a: leading upper case means an exported symbol, all upper case means
generic type. (Not Go 1 promise consistent) no special syntax/keyword
needed!

Choice b: struct name a=int, b=MyType {...}
No parse issue about ‘struct name’ followed by an identifier, right?

Choice c: leading and trailing underscore on generic placeholder
identifiers. Func MySqrt(x _t_)

These Examples are not deep thoughts. But the notion of no keyword or funky
symbol In the 99.99% of cases is a deep thought.

Michael
-- 

*Michael T. jonesmichael.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/CALoEmQwX5S70Zf5dwRCjaSO3Pppm2WpbD%3Dsrp9VLhD5UTO7srQ%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[Michael Jones]

So it seems! nothing substantive on the hard part.

On Wed, Jul 22, 2020 at 5:02 PM Russ Cox  wrote:

> So it sounds like everyone is in favor of the entire generics proposal and
> all the semantics, and all we have left to hammer out is the bracket
> characters? Do I have that right?
>
> Best,
> Russ
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA8EjDRrEBeOgs2Yax%2BgtHp-oJqCApjGJJEsop-S1OzOJbU3xA%40mail.gmail.com
> 
> .
>
-- 

*Michael T. jonesmichael.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/CALoEmQyUQPGYKGLfVvdHLrvyPq4X2Vc5RLZcWSv6Kqm8hghZ6Q%40mail.gmail.com.

Re: [go-nuts] [Generics] Feedback on updated draft

[Aleksey Tulinov]

Hmm. I must have read the previous version, but it probably was some
time ago. I have to say that i like the previous version more than the
current one.

I definitely don't like this:

type structField interface {
  type struct { a int; x int },
struct { b int; x float64 },
struct { c int; x uint64 }
}

If this is more readable than `require (a) { a.x++ }`, then i don't
even know what to say. My understanding of readability must be very
different.

I admit that there is a point in those concerns too, it's not
immediately obvious what `require (a) { a.x++ }` is supposed to do.

However the real point is not in a syntax, but in decoupling require
expression from constraint, so it's more generic and extensibleso to
speak. So maybe:

type IncrementX interface {
  require (a) {
evaluates(a.x) && evaluates(a.x++)
   // where evaluates() is defined elsewhere like `require (x) { x }`
  }
}

And type requirement could be `require { type int, int8, int16, int32,
int64 }`? Even though this still doesn't look right to me.

>The objection you mention to the approach used in the current draft is 
>something like: what if Go changes such that operators (other than == and !=) 
>apply to types other than primitive types?  But we're in charge of Go;

Yeah, sure. But there will be some code out there that depends on
existing constraints. If I understand this correctly, `Ordered` in the
current proposal does not define constraint that require operator `<`,
it defines a specific set of types and exploits a side effect that
operator '<' can be applied to every type from this set. This
introduces other side effects, for example, operator `==` is also
defined for all those types, so at least it defines what it wasn't
supposed to define.

I'm not sure if this is OK or not, just saying, but if Go somehow
changes "interface" of types under `Ordered`, then I think `Ordered`
will indirectly change its meaning because it will inherit those
changes even if they are unrelated to operator `<` or ordering in
general. Just wanted to point out that side effects work both ways,
and if those side effects are already exploited in existing Go code,
then it might be harder to change other parts that at first sight are
completely unrelated to what is being changed. Hope this helps.

But I dig the idea of releasing this in parts, i'll be keeping track
of this, this is a much needed feature. Thank you for looking into
this.

чт, 23 июл. 2020 г. в 00:21, Ian Lance Taylor :
>
> On Wed, Jul 22, 2020 at 1:46 PM Aleksey Tulinov
>  wrote:
> >
> > I'm not really a language designer and i don't use Go extensively, so
> > please take my words with a grain of salt. But I like Go and would
> > like to use it, and I'd like to put my 2 cents into the jar. I'm sorry
> > if this was already discussed, I checked the mailing list but didn't
> > find this.
> >
> > I've read the updated draft (sorry i'm late) and the thing that really
> > rubbed me the wrong way was this one:
> >
> > "We need a way to write a constraint that accepts only types that
> > support <. In order to do that, we observe that, aside from two
> > exceptions that we will discuss later, all the arithmetic, comparison,
> > and logical operators defined by the language may only be used with
> > types that are predeclared by the language, or with defined types
> > whose underlying type is one of those predeclared types. That is, the
> > operator < can only be used with a predeclared type such as int or
> > float64, or a defined type whose underlying type is one of those
> > types. Go does not permit using < with a composite type or with an
> > arbitrary defined type."
> >
> > This is a good observation, but what if Go changes in the future and
> > this observation is no longer true?
> >
> > I think I somewhat understand the underlying problem, interface is a
> > concept from the Java world and in Java "everything is object", and
> > classic interface is limited to describing methods, etc etc. But
> > interface is a form of constraint, so it does make a lot of sense to
> > use it as a constraint for generic types. However, I thought that
> > intention was to describe a constraint on objects composition, but
> > instead it describes constraints on object types. This doesn't feel
> > quite right.
> >
> > "If C++ and Java are about type hierarchies and the taxonomy of types,
> > Go is about composition." Am i right?
> >
> > Was it considered to decouple constraints into 1) constraints and 2)
> > constraints requirement expression? Something like this (here and
> > below everything is pseudocode):
> >
> > type comparable interface {
> >   require (a, b) {
> > a < b
> >   }
> > }
> >
> > When constraint is checked, this requirement can be rewritten as a
> > function for a concrete type, for example, for interface{}:
> >
> > func comparableRequireInterface(a, b interface{}) {
> >   _ = (a < b) // this won't compile, as expected, there is no operator
> > <, requirement isn't satisfied
> > }

Re: [go-nuts] Generics and parentheses

[David Riley]

On Jul 22, 2020, at 8:02 PM, Russ Cox  wrote:
> 
> So it sounds like everyone is in favor of the entire generics proposal and 
> all the semantics, and all we have left to hammer out is the bracket 
> characters? Do I have that right?

We haven't covered what the bike shed roof is going to be made from, but other 
than that, assuming things like type switches are planned to be solved in the 
end, I'm happy with it.


- Dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/71B4F56E-471C-4AD3-9B24-7BF3BE136BCE%40gmail.com.

Re: [go-nuts] Generics and parentheses

[Michal Strba]

Very correct! At least from my perspective.

On Thu, 23 Jul 2020 at 02:02 Russ Cox  wrote:

> So it sounds like everyone is in favor of the entire generics proposal and
> all the semantics, and all we have left to hammer out is the bracket
> characters? Do I have that right?
>
> Best,
> Russ
>
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/7t-Q2vt60J8/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/CAA8EjDRrEBeOgs2Yax%2BgtHp-oJqCApjGJJEsop-S1OzOJbU3xA%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/CAO6k0usy2JKtkKgtkfNeveLv9X%2B7YiO0mjHbna2o%2B5ef4%2BRBow%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[David Riley]

On Jul 15, 2020, at 4:59 PM, Ian Lance Taylor  wrote:
> 
> On Wed, Jul 15, 2020 at 5:44 AM Jan Mercl <0xj...@gmail.com> wrote:
>> 
>> My 2c - Alternative type parameters syntax (ab)using @$:
>> https://docs.google.com/document/d/1AoU23DcNxYX2vYT20V2K16Jzl7SP9taRRhIT8l_pZss/edit?usp=sharing
> 
> Thanks for the detailed writeup.  I'm a bit concerned about name
> scoping.  Also about the fact that constraints can apparently show up
> anywhere; is that always going to work?  And I don't think that
> Vector@$T is going to be all that intuitive for anybody to read.

Well, it should make the VMS programmers happier.


- Dave

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

Re: [go-nuts] Generics and parentheses

[Russ Cox]

So it sounds like everyone is in favor of the entire generics proposal and
all the semantics, and all we have left to hammer out is the bracket
characters? Do I have that right?

Best,
Russ

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

Re: [go-nuts] Generics and parentheses

[Denis Cheremisov]

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

a * b;

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

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

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

> With angled brackets, do we really need the colon or dot on both sides?  
> Wouldn't it be enough to just have it on the left to eliminate the parse 
> time ambiguities?  Like f<:int> or f<.int>?
>
> On Wed, 22 Jul 2020, 22:46 Евгений Кошевой,  wrote:
>
>> Maybe something like this:
>> using <.Type.>
>> func f(T<.int.>)
>> struct{ T<.int.> }
>> interface{ T<.int.> }
>> []T<.int.>{}
>>
>> среда, 22 июля 2020 г. в 01:12:32 UTC+3, Steven Blenkinsop: 
>>
>>> On Tue, Jul 21, 2020 at 3:12 PM, Michal Strba  
>>> wrote:
>>>
 I'd say a dot is necessary when instantiating a function call but 
 unnecessary when instantiating a type because it's always syntactically 
 clear when a type is required.

>>>
>>> That's not true in Go. Conversions look like function calls:
>>>
>>>   y := f(x)
>>>
>>> could be a conversion or a function call, depending on whether f is a 
>>> function or a type. If you need to use type parameters on f, the same 
>>> parsing problems present themselves whether it's a parameterized type or a 
>>> type parametric function.
>>>
 -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/a6a400ee-b9e2-4f30-a82d-a39ad8f5aaafn%40googlegroups.com
>>  
>> 
>> .
>>
>

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

Re: [go-nuts] What should be a silly protoc golang question

[burak serdar]

On Wed, Jul 22, 2020 at 4:32 PM John  wrote:
>
> Mathew + Burak,
>
> That was it.
>
> Out of curiosity, where did you find that option.  I didn't see it in 
> protoc's help. google search for "protoc --go_opt" did not yield good 
> results.  It did find: https://grpc.io/docs/languages/go/quickstart/, but I'd 
> like to bookmark the definite list if you know where i can find it.

https://developers.google.com/protocol-buffers/docs/reference/go-generated


>
> Cheers and thanks so much!
>
>
> On Wednesday, July 22, 2020 at 3:17:09 PM UTC-7, Matthew Walster wrote:
>>
>> John,
>>
>> On Wed, 22 Jul 2020 at 23:02, John  wrote:
>>>
>>> I then enter that directory and do:
>>>
>>> /usr/local/bin/protoc -I =./ ./name.proto --go_out=plugins=grpc:./ 
>>> --proto_path=/home/user/go/src
>>>
>>> This works, however it doesn't generate the go files in that directory, it 
>>> generates it inside the proto's directory with a directory structure like:
>>
>>
>> Have you tried using an option like: --go_opt=paths=source_relative
>>
>> Matthew Walster
>
> --
> 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/71f0cd9b-6197-4c1e-94fa-a41df7f8cdeco%40googlegroups.com.

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

[go-nuts] Go Present slide syntax supported by talks.godoc.org

[Tong Sun]

Hi, 

I want to use the new Markdown Syntax instead of the old Legacy Present 
Syntax when writing my new Go Present slides. 

However I found that the new Markdown Syntax is not supported by 
talks.godoc.org yet, right? 

E.g., for the new Markdown Syntax Go Present slide at 
https://github.com/suntong/lang/blob/master/lang/Go/src/slides/subsection-test/subsection-markdown.slide

The corresponding 
https://talks.godoc.org/github.com/suntong/lang/lang/Go/src/slides/subsection-test/subsection-markdown.slide
 only 
gives me:

Internal server error.



Any recent plan to upgrade? Thx. 

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

Re: [go-nuts] What should be a silly protoc golang question

[John]

Mathew + Burak,

That was it.  

Out of curiosity, where did you find that option.  I didn't see it in 
protoc's help. google search for "protoc --go_opt" did not yield good 
results.  It did find: https://grpc.io/docs/languages/go/quickstart/, but 
I'd like to bookmark the definite list if you know where i can find it.

Cheers and thanks so much!

  
On Wednesday, July 22, 2020 at 3:17:09 PM UTC-7, Matthew Walster wrote:
>
> John,
>
> On Wed, 22 Jul 2020 at 23:02, John > 
> wrote:
>
>> I then enter that directory and do:
>>
>> /usr/local/bin/protoc -I =./ ./name.proto --go_out=plugins=grpc:./ 
>> --proto_path=/home/user/go/src
>>
>> This works, however it doesn't generate the go files in that directory, 
>> it generates it inside the proto's directory with a directory structure 
>> like:
>>
>
> Have you tried using an option like: --go_opt=paths=source_relative
>
> Matthew Walster
>

-- 
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/71f0cd9b-6197-4c1e-94fa-a41df7f8cdeco%40googlegroups.com.

Re: [go-nuts] Using GTSM with GRPC

[Robert Engels]

Your network is setup wrong... if you are relying on a router to enforce ttl 
decrement for security. You can more easily prevent IP spoofing on the local 
net (or at the router) and then just verify the IP network portion is correct. 
Easier with a simple IP table rather than doing it in user space. 

> On Jul 22, 2020, at 11:59 AM, Matthew Walster  wrote:
> 
> 
> One of the projects I'm playing with at the moment is going to have 
> long-lived low-traffic streaming sessions with GRPC, having both the client 
> and the server on the same subnet.
> 
> To prevent an attacker from sending spurious TCP RSTs etc from across the 
> internet, there is a mechanism called GTSM where the underlying IP connection 
> has the TTL field set to the maximum value (255) and the receiver ensures 
> that the value seen in the IP header is the same value. Any hops through 
> routers would decrement the TTL so it's impossible to hijack the connection 
> unless you happen to be connected with an address in the same broadcast 
> domain.
> 
> Now, I realise the operating system is the one that handles these incoming 
> packets and therefore it's not easy for Go to see what the TTL is on each 
> packet (without using a RawConn or similar) so it is a lot easier to just 
> filter out these packets using a local firewall (iptables or pf etc) and I 
> could just rewrite outgoing packets to have a this higher TTL, but I'm unsure 
> how to go about making the outbound connection set the higher TTL in the Go 
> code itself.
> 
> Is there any established best practice for modifying these kinds of practices 
> on connections, especially in regard to using GRPC? I know I can use 
> golang.org/x/net/ipv4 and use SetTTL(ttl), then hook that in with a 
> "WithDialer" DialOption, but that seems a little too hacky and I'm not sure 
> how cross-platform that is.
> 
> I considered using something like the TCP AO (RFC5925) instead, but 
> considering that GRPC (via MTLS) gives me all the authentication I need for 
> the data, that seems overkill and prone to opaque issues. I'm essentially 
> only worried about spoofed packets coming in trying to reset the TCP 
> connection.
> 
> Open to any suggestions, many thanks in advance!
> 
> Matthew Walster
> -- 
> 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/CADLW2vyWMJ-qty-UnH%3D00fKkiK%3DtNA8BtRfBCVNxfdrVaNLd0g%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/06ACD605-F8CF-4D68-8619-7B11AA4F01C4%40ix.netcom.com.

Re: [go-nuts] What should be a silly protoc golang question

[Matthew Walster]

John,

On Wed, 22 Jul 2020 at 23:02, John  wrote:

> I then enter that directory and do:
>
> /usr/local/bin/protoc -I =./ ./name.proto --go_out=plugins=grpc:./
> --proto_path=/home/user/go/src
>
> This works, however it doesn't generate the go files in that directory, it
> generates it inside the proto's directory with a directory structure like:
>

Have you tried using an option like: --go_opt=paths=source_relative

Matthew Walster

-- 
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/CADLW2vz3Qk2a7F%2BhEWE5pg%2B-RKmMuUjFwy91dEbzok645g8Fzw%40mail.gmail.com.

Re: [go-nuts] What should be a silly protoc golang question

[burak serdar]

On Wed, Jul 22, 2020 at 4:02 PM John  wrote:
>
> In essence, I'm switching over to the new go protocol buffer lib and protoc 
> libraries.
>
> In the new version, you are told to specify go_package option in the .proto 
> file.  So I updated all mine to have that:
>
>  go_package = "path/to/my/proto";
>
>
>
> I use a script that finds all my proto files and the generates the go files 
> by recursively moving through folders looking for .proto files.
>
> I then enter that directory and do:
>
> /usr/local/bin/protoc -I =./ ./name.proto --go_out=plugins=grpc:./ 
> --proto_path=/home/user/go/src

Have you tried the --go_opt=paths=source_relative option?

>
> This works, however it doesn't generate the go files in that directory, it 
> generates it inside the proto's directory with a directory structure like:
>
> ./path/to/my/proto/name.pb.go
>
> Where, what I want is:
>
> name.pb.go
>
> I've tired a bunch of different options, nothing seems to get me what I want.
>
> Anyone know where I'm going wrong here?
>
> Thanks!
>
>
>
>
> --
> 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/ad5c5812-37e3-4f84-bd1d-5fcfcc9cb28eo%40googlegroups.com.

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

[go-nuts] What should be a silly protoc golang question

[John]

In essence, I'm switching over to the new go protocol buffer lib and protoc 
libraries.

In the new version, you are told to specify go_package option in the .proto 
file.  So I updated all mine to have that:

 go_package = "path/to/my/proto";


I use a script that finds all my proto files and the generates the go files 
by recursively moving through folders looking for .proto files.

I then enter that directory and do:

/usr/local/bin/protoc -I =./ ./name.proto --go_out=plugins=grpc:./ 
--proto_path=/home/user/go/src

This works, however it doesn't generate the go files in that directory, it 
generates it inside the proto's directory with a directory structure like:

./path/to/my/proto/name.pb.go

Where, what I want is: 

name.pb.go

I've tired a bunch of different options, nothing seems to get me what I 
want.  

Anyone know where I'm going wrong here?

Thanks!




-- 
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/ad5c5812-37e3-4f84-bd1d-5fcfcc9cb28eo%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[Sahas Subramanian]

With angled brackets, do we really need the colon or dot on both sides?
Wouldn't it be enough to just have it on the left to eliminate the parse
time ambiguities?  Like f<:int> or f<.int>?

On Wed, 22 Jul 2020, 22:46 Евгений Кошевой, 
wrote:

> Maybe something like this:
> using <.Type.>
> func f(T<.int.>)
> struct{ T<.int.> }
> interface{ T<.int.> }
> []T<.int.>{}
>
> среда, 22 июля 2020 г. в 01:12:32 UTC+3, Steven Blenkinsop:
>
>> On Tue, Jul 21, 2020 at 3:12 PM, Michal Strba  wrote:
>>
>>> I'd say a dot is necessary when instantiating a function call but
>>> unnecessary when instantiating a type because it's always syntactically
>>> clear when a type is required.
>>>
>>
>> That's not true in Go. Conversions look like function calls:
>>
>>   y := f(x)
>>
>> could be a conversion or a function call, depending on whether f is a
>> function or a type. If you need to use type parameters on f, the same
>> parsing problems present themselves whether it's a parameterized type or a
>> type parametric function.
>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/a6a400ee-b9e2-4f30-a82d-a39ad8f5aaafn%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] [Generics] Feedback on updated draft

[Ian Lance Taylor]

On Wed, Jul 22, 2020 at 1:46 PM Aleksey Tulinov
 wrote:
>
> I'm not really a language designer and i don't use Go extensively, so
> please take my words with a grain of salt. But I like Go and would
> like to use it, and I'd like to put my 2 cents into the jar. I'm sorry
> if this was already discussed, I checked the mailing list but didn't
> find this.
>
> I've read the updated draft (sorry i'm late) and the thing that really
> rubbed me the wrong way was this one:
>
> "We need a way to write a constraint that accepts only types that
> support <. In order to do that, we observe that, aside from two
> exceptions that we will discuss later, all the arithmetic, comparison,
> and logical operators defined by the language may only be used with
> types that are predeclared by the language, or with defined types
> whose underlying type is one of those predeclared types. That is, the
> operator < can only be used with a predeclared type such as int or
> float64, or a defined type whose underlying type is one of those
> types. Go does not permit using < with a composite type or with an
> arbitrary defined type."
>
> This is a good observation, but what if Go changes in the future and
> this observation is no longer true?
>
> I think I somewhat understand the underlying problem, interface is a
> concept from the Java world and in Java "everything is object", and
> classic interface is limited to describing methods, etc etc. But
> interface is a form of constraint, so it does make a lot of sense to
> use it as a constraint for generic types. However, I thought that
> intention was to describe a constraint on objects composition, but
> instead it describes constraints on object types. This doesn't feel
> quite right.
>
> "If C++ and Java are about type hierarchies and the taxonomy of types,
> Go is about composition." Am i right?
>
> Was it considered to decouple constraints into 1) constraints and 2)
> constraints requirement expression? Something like this (here and
> below everything is pseudocode):
>
> type comparable interface {
>   require (a, b) {
> a < b
>   }
> }
>
> When constraint is checked, this requirement can be rewritten as a
> function for a concrete type, for example, for interface{}:
>
> func comparableRequireInterface(a, b interface{}) {
>   _ = (a < b) // this won't compile, as expected, there is no operator
> <, requirement isn't satisfied
> }
>
> For struct{}:
>
> func comparableRequireStruct(a, b struct{}) {
>   _ = (a < b) // this won't compile either
> }
>
> For numeric types, specifically for int:
>
> func comparableRequireInt(a, b int) {
>   _ = (a < b) // this will compile for other numeric types too
> }
>
> Playground link: https://play.golang.org/p/vzk6l7zvBY_J
>
> Note that `require (a, b) { a == b }` will be satisfied for structs,
> interfaces, numerics and strings.
>
> This may (or may not) eliminate the need for predeclared `comparable`
> constraint and it might (or might not) answer this: "It's not clear
> that we fully understand the use of composite types in type lists":
>
> type IncrementX interface {
>   require (a) {
> a.x++
>   }
> }
>
> Which can be rewritten for a concrete type:
>
> type ConcreteStruct struct {
>   x float64
> }
>
> As
>
> func checkIncrementXConcreteStruct(a ConcreteStruct) {
>   a.x++ // note that it can not be rewritten to _ = (a.x++)
> }
>
> With empty `struct{}` it will give a sensible error message:
> "./prog.go:28:3: a.x undefined (type struct {} has no field or method
> x)" and it will detect error when ++ can not be applied:
> "./prog.go:24:5: invalid operation: a.x++ (non-numeric type string)"
>
> Does any of this make any sense?
>
> P.S. Yeah, it looks like C++, full disclosure, this is why I'm writing
> this email, I thought maybe Go could borrow something from there. I
> believe GCC 10+ can compile C++ concepts and there is a "playground"
> available at godbolt.org.


Thanks for the note.

What you are describing has some similarities to the first contracts
design draft, which you can read at
https://go.googlesource.com/proposal/+/764389869b7ca634cb88d134ff8c4c9f67c0be9b/design/go2draft-contracts.md
.

People raised significant objections to the approach described there
on the grounds of complexity.  In particular, it's hard to look at the
requirements and understand exactly what operations are permitted in
the generic function body.  For example, it's very tempting to say "if
< is supported, then <= is supported".  Or "if + is supported, then +=
is supported, and vice-versa."  It's tedious to have to write your
requires statement to list both "+" and "+=".  But then there are
quite a few such rules that have to be written down and understood.
It's hard to find an approach that is both easy to understand and easy
to use.  In fact in general it's quite hard to understand.

The objection you mention to the approach used in the current draft is
something like: what if Go changes such that operators (other than ==
and !=) apply to types 

Re: [go-nuts] Generics and parentheses

[Евгений Кошевой]

Maybe something like this:
using <.Type.>
func f(T<.int.>)
struct{ T<.int.> }
interface{ T<.int.> }
[]T<.int.>{}

среда, 22 июля 2020 г. в 01:12:32 UTC+3, Steven Blenkinsop: 

> On Tue, Jul 21, 2020 at 3:12 PM, Michal Strba  wrote:
>
>> I'd say a dot is necessary when instantiating a function call but 
>> unnecessary when instantiating a type because it's always syntactically 
>> clear when a type is required.
>>
>
> That's not true in Go. Conversions look like function calls:
>
>   y := f(x)
>
> could be a conversion or a function call, depending on whether f is a 
> function or a type. If you need to use type parameters on f, the same 
> parsing problems present themselves whether it's a parameterized type or a 
> type parametric function.
>
>>

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

[go-nuts] [Generics] Feedback on updated draft

[Aleksey Tulinov]

Hi,

I'm not really a language designer and i don't use Go extensively, so
please take my words with a grain of salt. But I like Go and would
like to use it, and I'd like to put my 2 cents into the jar. I'm sorry
if this was already discussed, I checked the mailing list but didn't
find this.

I've read the updated draft (sorry i'm late) and the thing that really
rubbed me the wrong way was this one:

"We need a way to write a constraint that accepts only types that
support <. In order to do that, we observe that, aside from two
exceptions that we will discuss later, all the arithmetic, comparison,
and logical operators defined by the language may only be used with
types that are predeclared by the language, or with defined types
whose underlying type is one of those predeclared types. That is, the
operator < can only be used with a predeclared type such as int or
float64, or a defined type whose underlying type is one of those
types. Go does not permit using < with a composite type or with an
arbitrary defined type."

This is a good observation, but what if Go changes in the future and
this observation is no longer true?

I think I somewhat understand the underlying problem, interface is a
concept from the Java world and in Java "everything is object", and
classic interface is limited to describing methods, etc etc. But
interface is a form of constraint, so it does make a lot of sense to
use it as a constraint for generic types. However, I thought that
intention was to describe a constraint on objects composition, but
instead it describes constraints on object types. This doesn't feel
quite right.

"If C++ and Java are about type hierarchies and the taxonomy of types,
Go is about composition." Am i right?

Was it considered to decouple constraints into 1) constraints and 2)
constraints requirement expression? Something like this (here and
below everything is pseudocode):

type comparable interface {
  require (a, b) {
a < b
  }
}

When constraint is checked, this requirement can be rewritten as a
function for a concrete type, for example, for interface{}:

func comparableRequireInterface(a, b interface{}) {
  _ = (a < b) // this won't compile, as expected, there is no operator
<, requirement isn't satisfied
}

For struct{}:

func comparableRequireStruct(a, b struct{}) {
  _ = (a < b) // this won't compile either
}

For numeric types, specifically for int:

func comparableRequireInt(a, b int) {
  _ = (a < b) // this will compile for other numeric types too
}

Playground link: https://play.golang.org/p/vzk6l7zvBY_J

Note that `require (a, b) { a == b }` will be satisfied for structs,
interfaces, numerics and strings.

This may (or may not) eliminate the need for predeclared `comparable`
constraint and it might (or might not) answer this: "It's not clear
that we fully understand the use of composite types in type lists":

type IncrementX interface {
  require (a) {
a.x++
  }
}

Which can be rewritten for a concrete type:

type ConcreteStruct struct {
  x float64
}

As

func checkIncrementXConcreteStruct(a ConcreteStruct) {
  a.x++ // note that it can not be rewritten to _ = (a.x++)
}

With empty `struct{}` it will give a sensible error message:
"./prog.go:28:3: a.x undefined (type struct {} has no field or method
x)" and it will detect error when ++ can not be applied:
"./prog.go:24:5: invalid operation: a.x++ (non-numeric type string)"

Does any of this make any sense?

P.S. Yeah, it looks like C++, full disclosure, this is why I'm writing
this email, I thought maybe Go could borrow something from there. I
believe GCC 10+ can compile C++ concepts and there is a "playground"
available at godbolt.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/CAMteYTbyeYKV55dLja%2BYqtGELA_4vh%3DnsvJRuaa6RUoTZ_Nx_A%40mail.gmail.com.

Re: [go-nuts] template

[Lutz Horn]

I am running a website for which we use templates.


Do you use https://golang.org/pkg/html/template/? If yes, how do you use 
them? If no, this question is off-topic for this mailing list.


Lutz

--
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/AM7P191MB1060A58CEA463342E216714B9E790%40AM7P191MB1060.EURP191.PROD.OUTLOOK.COM.

Re: [go-nuts] Re: module questions

['K Richard Pixley' via golang-nuts]

Thank you!

I hadn't run into any references to that one in any of the doc.

On 7/21/20 23:56, Amnon wrote:

[External Email. Be cautious of content]

GOPRIVATE is your friend.

https://golang.org/cmd/go/#hdr-Module_configuration_for_non_public_modules 



On Monday, 20 July 2020 20:40:19 UTC+1, K Richard Pixley wrote:

I'm think I understand the go-1.14 downloadable module workflow.
But I'm
not getting how to use modules in an enterprise system where we
cannot
allow automated downloads or where I want to include packages from
one
local module in another where neither are available on any public
download server.

Are there instructions or discussion of the enterprise workflow
available anywhere?

--
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/847d22a8-0cb4-4ab0-af35-cad159724777o%40googlegroups.com 
.


--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/66f8e3c9-37e0-88cf-19a9-827b89c368c7%40juniper.net.

[go-nuts] Using GTSM with GRPC

[Matthew Walster]

One of the projects I'm playing with at the moment is going to have
long-lived low-traffic streaming sessions with GRPC, having both the client
and the server on the same subnet.

To prevent an attacker from sending spurious TCP RSTs etc from across the
internet, there is a mechanism called GTSM where the underlying IP
connection has the TTL field set to the maximum value (255) and the
receiver ensures that the value seen in the IP header is the same value.
Any hops through routers would decrement the TTL so it's impossible to
hijack the connection unless you happen to be connected with an address in
the same broadcast domain.

Now, I realise the operating system is the one that handles these incoming
packets and therefore it's not easy for Go to see what the TTL is on each
packet (without using a RawConn or similar) so it is a lot easier to just
filter out these packets using a local firewall (iptables or pf etc) and I
could just rewrite outgoing packets to have a this higher TTL, but I'm
unsure how to go about making the outbound connection set the higher TTL in
the Go code itself.

Is there any established best practice for modifying these kinds of
practices on connections, especially in regard to using GRPC? I know I can
use golang.org/x/net/ipv4 and use SetTTL(ttl), then hook that in with a
"WithDialer" DialOption, but that seems a little too hacky and I'm not sure
how cross-platform that is.

I considered using something like the TCP AO (RFC5925) instead, but
considering that GRPC (via MTLS) gives me all the authentication I need for
the data, that seems overkill and prone to opaque issues. I'm essentially
only worried about spoofed packets coming in trying to reset the TCP
connection.

Open to any suggestions, many thanks in advance!

Matthew Walster

-- 
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/CADLW2vyWMJ-qty-UnH%3D00fKkiK%3DtNA8BtRfBCVNxfdrVaNLd0g%40mail.gmail.com.

Re: [go-nuts] Allocating lots (e.g. a million) objects on the heap

[Jesper Louis Andersen]

On Mon, Jul 20, 2020 at 7:34 PM  wrote:

> I have an application where I will be allocating millions of data
> structures, all of the same size. My program will need to run continuously
> and be pretty responsive to
> its network peers.
>
>
I'd recommend quantifying "pretty responsive" in this case. Chances are you
can get away with not doing anything at all, depending on the requirements.

Go currently employs a concurrent garbage collector, which typically enjoys
very small pause times (less than 500 microseconds). You might be able to
use it to fulfill your goals, without having to resort to extra work. That
said, the more pointers your data have, the more work has to be done to
scan, so the structure of your data matters as well. Knowing a bit about
that data would help since you can often structure it in ways that are
efficient.

So the TL;DR version is: the work you have to do is exponential to how
efficient you have to do it. Chances are you have to spend a lot of time to
optimize. So make sure you have a need for optimization, before you start
doing it.

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

[go-nuts] Re: Allocating lots (e.g. a million) objects on the heap

[Amnon]

Try a naive solution, and see if it is good enough, 
before optimising.


On Monday, 20 July 2020 18:35:14 UTC+1, netconn...@gmail.com wrote:
>
> I have an application where I will be allocating millions of data 
> structures, all of the same size. My program will need to run continuously 
> and be pretty responsive to 
> its network peers.
>
> The data is fairly static, once allocated it will rarely need to be 
> modified or deleted.
>
> In order to minimize the garbage collection scanning overhead, I was 
> thinking of allocating large blocks on the heap that were a fixed size that 
> would hold 20K or so elements
> and then write a simple allocator to hand out pieces of those blocks when 
> needed. Instead of having to scan millions of items on the heap, the GC 
> would only be scanning 100 or so
> items.
>
> Sound reasonable?  Or does this 'go' against the golang way of doing 
> things?
>
> F
>

-- 
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/aac8728a-da18-4117-99b4-b472f897fb9co%40googlegroups.com.

[go-nuts] Re: module questions

[Amnon]

GOPRIVATE is your friend.

https://golang.org/cmd/go/#hdr-Module_configuration_for_non_public_modules

On Monday, 20 July 2020 20:40:19 UTC+1, K Richard Pixley wrote:
>
> I'm think I understand the go-1.14 downloadable module workflow. But I'm 
> not getting how to use modules in an enterprise system where we cannot 
> allow automated downloads or where I want to include packages from one 
> local module in another where neither are available on any public 
> download server. 
>
> Are there instructions or discussion of the enterprise workflow 
> available anywhere? 
>
>

-- 
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/847d22a8-0cb4-4ab0-af35-cad159724777o%40googlegroups.com.