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 {
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
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
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
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
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
[ ] 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]*,
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
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,
>
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;
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
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
>
>
>
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
>
>
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
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
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:
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
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
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
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
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 =
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
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
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
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
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
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.
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
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
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
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
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
32 matches
Mail list logo
