Re: [go-nuts] Better dependency management in go

2020-09-22 Thread 'Axel Wagner' via golang-nuts
Hi, On Tue, Sep 22, 2020 at 12:01 AM Shirshendu Bhowmick < shirshendu.bhowmi...@gmail.com> wrote: > There are some confusing syntax, for example > github.com/myorganzation/mypackage/pkg > This url results in 404 in browsers but somehow go resolves it, so it > seems like depending on hosting

Re: [go-nuts] Evaluation order of return

2020-09-21 Thread 'Axel Wagner' via golang-nuts
The evaluation order is defined here: https://golang.org/ref/spec#Order_of_evaluation The important part is that the order of evaluation in a return statement is only defined for function calls, method calls and communication statements, but not in relation to other operations. So, in return

Re: [go-nuts] mytex.RWLock recursive read lock

2020-09-21 Thread 'Axel Wagner' via golang-nuts
FTR, I still don't think the docs *are* ambiguous. The authoritative part is If a goroutine holds a RWMutex for reading and another goroutine might call > Lock, no goroutine should expect to be able to acquire a read lock until > the initial read lock is released. The rest is just additional

Re: [go-nuts] mytex.RWLock recursive read lock

2020-09-21 Thread 'Axel Wagner' via golang-nuts
On Mon, Sep 21, 2020 at 2:06 PM Henrik Johansson wrote: > Ambiguous docs however aren't generally good in any way. This came up as a > consequence of real code being changed by a new very skilled developer and > there was quite a bit discussion that could have been avoided with clearer > docs. >

Re: [go-nuts] mytex.RWLock recursive read lock

2020-09-21 Thread 'Axel Wagner' via golang-nuts
To elaborate a bit: You are correct in that there is a slight syntactic ambiguity whether "this prohibits" refers to the entire sentence ("if another goroutine might call Lock, then a second RLock might not be acquired"), or only to the second half. I would argue the rest of the section makes it

Re: [go-nuts] mytex.RWLock recursive read lock

2020-09-21 Thread 'Axel Wagner' via golang-nuts
It only says that's excluded *if* you can have a concurrent Lock call. On Mon, Sep 21, 2020 at 12:48 PM Henrik Johansson wrote: > Yes that's the canonical deadlock but doesn't the docs say > > "In particular, this prohibits recursive read locking" > > which it doesn't unless you mix reads and

Re: [go-nuts] mytex.RWLock recursive read lock

2020-09-21 Thread 'Axel Wagner' via golang-nuts
(Note, FWIW, that in particular no write locks need to be *held*. It's enough for Lock to be *called*, it doesn't have to have returned yet) On Mon, Sep 21, 2020 at 12:29 PM Axel Wagner wrote: > I feel like the docs are pretty precise in what they say and why. > > a blocked Lock call excludes

Re: [go-nuts] mytex.RWLock recursive read lock

2020-09-21 Thread 'Axel Wagner' via golang-nuts
I feel like the docs are pretty precise in what they say and why. a blocked Lock call excludes new readers from acquiring the lock. This means, the following could happen: Goroutine 1 calls RLock, acquires a Read-Lock Goroutine 2 calls Lock, blocking Goroutine 1 calls RLock again, blocking (as

Re: [go-nuts] hook into os.Stdout / os.Stderr

2020-09-20 Thread 'Axel Wagner' via golang-nuts
As os.Stdout/os.Stderr are *os.File, not io.Writer, you need to go a step further and use os.Pipe . Something like this: https://play.golang.org/p/V6ygCmwlsiz TBH, it's not great to do this. As you can tell from the code, this is pretty complicated and if you want

Re: [go-nuts] Should the program print true or false?

2020-09-17 Thread 'Axel Wagner' via golang-nuts
I think you might've intended this, which does indeed print true: type S []S var a, b S a, b = S{0: b}, S{0: a} fmt.Println(reflect.DeepEqual(a, b)) On Thu, Sep 17, 2020 at 6:03 PM Axel Wagner wrote: > I don't think the docs imply that. For one, a[0] is nil, and b[0] isn't. > > On Thu, Sep 17,

Re: [go-nuts] Should the program print true or false?

2020-09-17 Thread 'Axel Wagner' via golang-nuts
I don't think the docs imply that. For one, a[0] is nil, and b[0] isn't. On Thu, Sep 17, 2020 at 5:58 PM tapi...@gmail.com wrote: > > package main > > import ( > "fmt" > "reflect" > ) > > func main() { > f() > } > > func f() { > type S []S > var a, b S > a = S{0: b} > b = S{0: a}

Re: [go-nuts] method resolution order

2020-09-16 Thread 'Axel Wagner' via golang-nuts
On Wed, Sep 16, 2020 at 10:51 AM Stephan Lukits wrote: > Assume a public interface I with two methods NotInS and M whereas NotInS > is calling M. An implementation i of I which implements NotInS and M as > well as a specialization s of i which only implements M. Finally a > constructor whose

Re: [go-nuts] Proposal: auto return String instead of []byte if requested

2020-09-12 Thread 'Axel Wagner' via golang-nuts
Hi y'all, given that the concern here seems to be performance (though, TBH, I doubt this particular case is much of a bottleneck), this seems to be far simpler to address as a compiler optimization - if the compiler can prove there are no other references to a `[]byte`, it can do the conversion

Re: [go-nuts] Interface definition as type alias

2020-09-08 Thread 'Axel Wagner' via golang-nuts
The only real downsides, I think, are that compiler errors gets harder to read: https://github.com/golang/go/issues/21866 And likewise, that the name won't appear at runtime, so if you print things using `reflect`, the result will be less readable. I think there are cases where it has advantages,

Re: [go-nuts] how to declare type as interface{}

2020-09-03 Thread 'Axel Wagner' via golang-nuts
What's wrong with the first one? The second one doesn't work because there are not interface composite literals. So you need to actually have an interface{} variable to take the address of. The third one seems to work just fine: https://play.golang.org/p/zn2mL69VzPo On Thu, Sep 3, 2020 at 10:32

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

2020-09-02 Thread 'Axel Wagner' via golang-nuts
On Wed, Sep 2, 2020 at 7:02 PM Nishanth Shanmugham < nishanth.gerr...@gmail.com> wrote: > If it is intended at simplification for parsers, […] If it is intended to > improve readability for readers of generic code > I would argue that this is not a dichotomy. On the contrary: In general, a

Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

2020-09-02 Thread 'Axel Wagner' via golang-nuts
t;>>>>>>>> > if value2 == 0 { >>>>>>>>>>> > return true >>>>>>>>>>> > } >>>>>>>>>>> > >>>>>>>>>>> > o

Re: [go-nuts] rin: return if nil syntactic sugar

2020-08-31 Thread 'Axel Wagner' via golang-nuts
Oh, sorry: I mixed the history up. AIUI this is the same as the try proposal with a different keyword and *that* got rejected for the "magical" control flow. On Mon, Aug 31, 2020 at 9:00 AM Axel Wagner wrote: > On Mon, Aug 31, 2020 at 7:32 AM Zakaria wrote: > >> If the objections on the too

Re: [go-nuts] rin: return if nil syntactic sugar

2020-08-31 Thread 'Axel Wagner' via golang-nuts
On Mon, Aug 31, 2020 at 7:32 AM Zakaria wrote: > If the objections on the too magical handle part, why not cut that part > and retain the check part? > The objection was mainly on the too magical check part, AIUI. > > Most of the time the we just forward the error on to the next level >

Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

2020-08-27 Thread 'Axel Wagner' via golang-nuts
gt;>>>> >> >>>>>>>>>> >> I was trying to show that the current behavior is confusing >>>>>>>>>> and that fmt.Print() needing to resort to panic-and-recover is kinda >>>>>>>>>> code

Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

2020-08-27 Thread 'Axel Wagner' via golang-nuts
t;>> "I may or may not have a value here" (where Type is a value-type). >>>>>>>>> >> This is probably a bad practice on my behalf, because I break >>>>>>>>> the Liskov substitution principle: there is a value of `*Type`

Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

2020-08-27 Thread 'Axel Wagner' via golang-nuts
func (Type) String() string {...} >>>>>>> >> v *Type = {...} >>>>>>> >> _ = v.String() >>>>>>> >> >>>>>>> >> and have it compile, is syntactic sugar: `v` gets implicitly >>>>>>>

Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

2020-08-27 Thread 'Axel Wagner' via golang-nuts
>>> >> func (Type) String() string {...} >>>>> >> >>>>> >> v *Type = nil >>>>> >> r interface{} = v >>>>> >> _, ok = r.(Stringer) >>>>> >> >>>>> >

Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

2020-08-27 Thread 'Axel Wagner' via golang-nuts
`r`, `*r`, or `` defines >>> .String()?" - which matches the static semantics of `r.String()`. >>> >> >>> >> So, while I should probably not use *Type as a replacement for >>> Optional, I think it might make sense to have some operator that can >

Re: [go-nuts] Dynamic composition of interfaces at runtime?

2020-08-26 Thread 'Axel Wagner' via golang-nuts
Hi, no, there isn't really a solution to this. I've blogged about this: https://blog.merovius.de/2017/07/30/the-trouble-with-optional-interfaces.html A combination of generics and embedding can help. So, you can do type Wrapper[T] struct { T otherFields } func (w *Wrapper)

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

2020-08-21 Thread 'Axel Wagner' via golang-nuts
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

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

2020-08-21 Thread 'Axel Wagner' via golang-nuts
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: > >>

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

2020-08-21 Thread 'Axel Wagner' via golang-nuts
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

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

2020-08-21 Thread 'Axel Wagner' via golang-nuts
> On Fri, 21 Aug 2020 at 15:24, Ian Lance Taylor wrote: > >> On Fri, Aug 21, 2020, 12:37 AM 'Axel Wagner' via golang-nuts < >> golang-nuts@googlegroups.com> wrote: >> >>> Just to clarify, the intent is to make the declaration in the spec `type >>> any

Re: [go-nuts] [string] multiline stirng and break line "\n"

2020-08-21 Thread 'Axel Wagner' via golang-nuts
Hey, the `-quotes denote a "raw string literal". Escape-sequences in raw string literals are not interpreted - that's basically their purpose. So `t2` contains the literal two-byte sequence `\n`. You can see that in the output of `fmt.Println`, the newline is a 10, but t2 does not contain a 10,

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

2020-08-21 Thread 'Axel Wagner' via golang-nuts
Just to clarify, the intent is to make the declaration in the spec `type any = interface{}`, not `type any interface{}`, correct? The latter would be more analogous to `error`. Either has certain advantages and disadvantages, I'm not sure which I prefer, but I just want to make sure I understand

Re: [go-nuts] Re: best way to know executable version without running it

2020-08-19 Thread 'Axel Wagner' via golang-nuts
AIUI, the version number output by `consul version` is not specified by Go, but by the consul source itself. As far as Go is concerned, it's just be a string constant (or maybe even a dynamically assembled string from integer constants or Anything really). As such, there is no really reliable

Re: [go-nuts] [generics] Type list syntax

2020-08-18 Thread 'Axel Wagner' via golang-nuts
On Tue, Aug 18, 2020 at 9:04 PM Frederik Zipp wrote: > I'd argue that every type expresses a certain subset of types, not just > interfaces. For the other types the size of the subset just happens to be 1 > (each containing just itself). > You can certainly argue that. Though FTR, conceptually

Re: [go-nuts] [generics] Type list syntax

2020-08-18 Thread 'Axel Wagner' via golang-nuts
On Tue, Aug 18, 2020 at 8:29 PM Frederik Zipp wrote: > The more I think about it the less I understand why type list should > reside inside interfaces. I can only think of two reasons: > > 1) Avoid a new keyword for type lists. > 2) The idea that only interfaces should be able to act as

Re: [go-nuts] [generics] Type list syntax

2020-08-18 Thread 'Axel Wagner' via golang-nuts
On Tue, Aug 18, 2020 at 6:00 PM Frederik Zipp wrote: > axel.wa...@googlemail.com schrieb am Dienstag, 18. August 2020 um > 17:44:16 UTC+2: > >> I think in the overwhelmingly common case (a type-list being a list of >> identifiers or short type-constructors like channels or slices), having a >>

Re: [go-nuts] [generics] Type list syntax

2020-08-18 Thread 'Axel Wagner' via golang-nuts
I think in the overwhelmingly common case (a type-list being a list of identifiers or short type-constructors like channels or slices), having a line per item takes up a lot of vertical real-estate for little use. Also, hopefully, almost never would really use them anyway, with basically all

Re: [go-nuts] map without default values

2020-08-14 Thread 'Axel Wagner' via golang-nuts
On Fri, Aug 14, 2020 at 8:52 PM Joe Marty wrote: > >> If I know that a value exists, or am fine using the zero value (again, >> that's the majority of my personal use-cases for maps at least), having to >> use a statement just to discard the extra bool is annoying. >> > > Right, so this brings

Re: [go-nuts] map without default values

2020-08-14 Thread 'Axel Wagner' via golang-nuts
the "comma OK" approach that Axel shared. In your case, >> adding, and deleting could complain if there is already a matching entry, >> or not a matching entry, or -- and this is the real reason -- by looking at >> the payload of a new or matching entry to use applica

Re: [go-nuts] map without default values

2020-08-13 Thread 'Axel Wagner' via golang-nuts
No, there isn't, but you can check if the value exists: x, ok := m[k] if !ok { panic("does not exist") } You can also wrap that with methods, if you want to avoid the extra check. I disagree with you that panicking on a non-existent key is better - either in general, or in the majority of

Re: [go-nuts] generics go2go Type List in Interface - Struct Type

2020-08-11 Thread 'Axel Wagner' via golang-nuts
Yes, it's intended. From the draft: More precisely, the underlying type of the type argument must be identical > to the underlying type of one of the types in the type list. Type-lists match by underlying type of both argument and the types in the type-list. As SantaHappy and SantaSad both have

Re: [go-nuts] Re: Generics: after type lists

2020-08-08 Thread 'Axel Wagner' via golang-nuts
On Sat, Aug 8, 2020 at 5:58 AM 'Carla Pfaff' via golang-nuts < golang-nuts@googlegroups.com> wrote: > On Saturday, 8 August 2020 at 01:33:59 UTC+2 Patrick Smith wrote: > >> if we think it likely that a future version of Go will allow operator >> overloading >> > > That's highly unlikely:

Re: [go-nuts] Generics and parentheses

2020-08-06 Thread 'Axel Wagner' via golang-nuts
On Thu, Aug 6, 2020 at 9:26 PM 'Red Daly' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Have the authors considered the implications of requiring the `type` > keyword to use a generic type, not just at declaration time? Would this > open up more syntax possibilities, such as `var x T`?

Re: [go-nuts] "Interfaces" with type lists are a strange beast

2020-08-06 Thread 'Axel Wagner' via golang-nuts
On Thu, Aug 6, 2020 at 8:53 PM Ian Lance Taylor wrote: > My point wasn't that a string is a number. My point was that the > current design draft permits writing a function that uses + and works > with both strings and numbers. Is there a need for that? I can't really imagine one. That being

Re: [go-nuts] How do you write "member" with the proposed generics draft?

2020-08-04 Thread 'Axel Wagner' via golang-nuts
Prolly. Except OP specifically asked about "not that" :) On Tue, Aug 4, 2020 at 5:30 PM Andrei Tudor Călin wrote: > I feel like https://go2goplay.golang.org/p/RLn9BXjU1OR is a better > compromise than having two functions. > > On Tue, Aug 4, 2020 at 5:50 PM 'Axel W

Re: [go-nuts] How do you write "member" with the proposed generics draft?

2020-08-04 Thread 'Axel Wagner' via golang-nuts
No, that's not possible. A generic function can only work with *either* built in operators *or* methods. So, you always need to have two functions: https://go2goplay.golang.org/p/YuzSzDAOEo2 On Tue, Aug 4, 2020 at 4:32 PM Juliusz Chroboczek wrote: > I'd be grateful if people could give me an

Re: [go-nuts] "Interfaces" with type lists are a strange beast

2020-08-03 Thread 'Axel Wagner' via golang-nuts
On Tue, Aug 4, 2020 at 1:01 AM Ben Hoyt wrote: > In terms of a "solution" for this, one that I'm sure has been thought > about: what about keeping type constraints and interfaces completely > separate? They are half the time anyway (when there are type lists), > so why not make them separate all

Re: [go-nuts] errors in generated go files

2020-07-28 Thread 'Axel Wagner' via golang-nuts
Maybe this helps? https://golang.org/src/cmd/compile/doc.go#L153 On Tue, Jul 28, 2020 at 8:35 PM 'K Richard Pixley' via golang-nuts < golang-nuts@googlegroups.com> wrote: > I'm currently working with pigeon, a peg based parser generator. > > When I... > >- make a go error in the source file,

Re: [go-nuts] why "unsafe.Sizeof(a[0])" doesn't generate panic when a is nil

2020-07-27 Thread 'Axel Wagner' via golang-nuts
`unsafe` is a magic package. It is provided by the language and entirely implemented as compiler-intrinsics - and at compile-time. In particular, the result of `unsafe.Sizeof` must be a compile-time constant . In

Re: [go-nuts] [Generics] Constraints package name

2020-07-26 Thread 'Axel Wagner' via golang-nuts
On Sun, Jul 26, 2020 at 1:05 PM wrote: > Also, the name "is" doesn't follow the usual naming style of Go packages. >> > > I'm not sure if there is a Go standard library package naming style other > than "relatively short name". > "relatively short name" is less consistently applied than "be

Re: [go-nuts] [generics] Type embedding in generic types

2020-07-21 Thread 'Axel Wagner' via golang-nuts
On Tue, Jul 21, 2020 at 10:54 AM 'Javier Zunzunegui' via golang-nuts < golang-nuts@googlegroups.com> wrote: > It's not A(B,C,D) vs A(B(C(D))), both are supported with & without > embedding. My issue is with a linked list that requires a new type for each > additional node. It is potentially an

Re: [go-nuts] [generics] Type embedding in generic types

2020-07-21 Thread 'Axel Wagner' via golang-nuts
Why do you feel that a type A(B, C, D, E) should be supported, but A(B(C(D(E))) shouldn't? They are equivalent in expressiveness. And to be clear, I'd also prefer A(B, C, D, E) for this use, but ISTM this isn't possible without variadic type-parameters (i.e. I'd need a way to express "this

Re: [go-nuts] [generics] Type embedding in generic types

2020-07-20 Thread 'Axel Wagner' via golang-nuts
Hi, given the discussion here, the blog post I just published might be interesting: https://blog.merovius.de/2020/07/20/parametric-context.html To the best of my knowledge, what I describe there is only really doable using embedded type-parameters. As I state in the conclusion, I'm not entirely

Re: [go-nuts] Go 2 review process

2020-07-20 Thread 'Axel Wagner' via golang-nuts
Hi, ISTM that all those filtering-suggestions are quietly redefining the problem. The Go team didn't say "we don't have time to read all proposals", they said "we don't have time to argue every proposal in-depth". So if your concern was "that is bad, because I want all proposals to get enough

Re: [go-nuts] Re: Generics and parentheses

2020-07-20 Thread 'Axel Wagner' via golang-nuts
On Mon, Jul 20, 2020 at 8:33 AM Xie Zhenye wrote: > Gramma of a programming language is not able to be changed after released. > So language design is elegant or not is more important than difficulty of > implementing. > > Adding type information in parse time and use angle brackets only affects

Re: [go-nuts] Go 2 review process

2020-07-18 Thread 'Axel Wagner' via golang-nuts
There seems to be an assumption that, given enough time and effort, any idea could get accepted into the language. But that clearly can't be so. It might be frustrating to hear that your particular idea just isn't considered a good idea, but it's a necessity that most ideas go that route. It's not

Re: [go-nuts] Generics and parentheses

2020-07-16 Thread 'Axel Wagner' via golang-nuts
I dislike the idea of using $ and @ because I don't want to add new symbols to the language, if it can be avoided. In general I'd argue that Go tends to use keywords instead of symbols to convey meaning - e.g. we don't write `a -> b`, but `func(a) b`. There are exceptions (pointers are a big one)

Re: [go-nuts] [generics]The ability to allow different length arrays and slices

2020-07-15 Thread 'Axel Wagner' via golang-nuts
Why not just accept slices only and expect the caller to add a `[:]`? It's not quite as ergonomic, but should have the same effect and we wouldn't need to add complexity to the design. On Wed, Jul 15, 2020 at 4:58 PM wrote: > Right now as I understand it, I would still have to write a different

Re: [go-nuts] var fn myHandler = func(){ fn }

2020-07-12 Thread 'Axel Wagner' via golang-nuts
On Sun, Jul 12, 2020 at 9:33 PM Bakul Shah wrote: > On Jul 12, 2020, at 11:11 AM, Gert wrote: > > > > https://play.golang.org/p/6xMgjr1IyFD > > > > var fn myHandler > > fn = func(w http.ResponseWriter, r *http.Request) { > > fn.GET(w, r) > > } > > > > Just wondering if it's possible somehow

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

2020-06-30 Thread 'Axel Wagner' via golang-nuts
Hm, though I guess in terms of compatibility, it should be mentioned that according to the design, this currently valid program wouldn't build at go1.(N-1) (and later, unless the `foo` build tag is specified): https://play.golang.org/p/436NUYC7rno If that's okay, then maybe mandating build tags is

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

2020-06-30 Thread 'Axel Wagner' via golang-nuts
On Wed, Jul 1, 2020 at 1:10 AM roger peppe wrote: > LGTM. This is a welcome change. I often need to look up how to spell > "// +build" currently :) > > One thing I'd really like to see is the eventual deprecation of > filename-based build constraints (e.g. file_linux.go). > They make it hard for

Re: [go-nuts] Generics feedback

2020-06-28 Thread 'Axel Wagner' via golang-nuts
Readability, at the end of the day, is subjective. So, personally: Yes, I absolutely find it more readable than any alternative that has been suggested. Personally, when I see code using a bunch of extra symbols that have special meaning (Perl and Haskell are extreme examples), I tend to "zone

Re: [go-nuts] Is it necessary to start function names within main package with capitalized letter?

2020-06-24 Thread 'Axel Wagner' via golang-nuts
Personally, I tend to do it. Note that it doesn't actually make a difference from a technical perspective - main can't be imported, so it makes no real sense to export any identifiers. As such, the boundaries of what I "export" are somewhat more fluent than usual. But yeah, as you said, for

Re: [go-nuts] Re: [generics] I think it's better have higher perfomance than lower compiling time

2020-06-21 Thread 'Axel Wagner' via golang-nuts
Why not just build your release-build with gccgo? It often already gives better performance than gc, AIUI. If enough of the people who really care about it would focus their energy on it, that could probably get even more pronounced. There's no reason that gc needs to grow optimization knobs, if

Re: [go-nuts] [generics] no methods with type parameters

2020-06-20 Thread 'Axel Wagner' via golang-nuts
Also, just FTR, I agree with you that it would be nice to have type-parameters on methods. I would very much like it if there was a way to make it work. However, your tone is very confrontational. The people who wrote that design have spent a lot more time on thinking about this than you and you

Re: [go-nuts] [generics] no methods with type parameters

2020-06-20 Thread 'Axel Wagner' via golang-nuts
You have not responded to the second concern, about interface-type-assertions requiring runtime instantiation of methods. On Sat, Jun 20, 2020 at 6:20 PM Carsten Orthbandt < carsten.orthba...@gmail.com> wrote: > Reflection certainly is a potential problem. But the only actual issue I > can see

Re: [go-nuts] Re: [generics] how to constraint a type must be a map or a slice?

2020-06-20 Thread 'Axel Wagner' via golang-nuts
Maps and Slices don't have a lot of operations in common. In general, the only ones I can think of are - `make(T, someInt)`, though it means *very* different things for both, so a generic function doing this is likely not super sensible - `for _, v := range x`, though even this differs, as the

Re: [go-nuts] [generics] no methods with type parameters

2020-06-20 Thread 'Axel Wagner' via golang-nuts
One way to see a problem pretty immediately is that `reflect` allows you to look up a type's method by name, but it doesn't allow you to do the same for functions. So you'd need a runtime-representation of generic functions of *some* sort. This is currently avoided by the restriction that you

Re: [go-nuts] Re: [generics] how to constraint a type must be a map or a slice?

2020-06-20 Thread 'Axel Wagner' via golang-nuts
I would assume it's type MapConstraint(type K comparable, V interface{}) interface { type map[K]V } func F(type M MapConstraint(K, V), K comparable, V interface{}) (m M) { } Note that you are under no obligation to make use of a type-parameter if you don't need it. On Sat, Jun 20, 2020 at

Re: [go-nuts] [generics] Infer types on return

2020-06-19 Thread 'Axel Wagner' via golang-nuts
On Fri, Jun 19, 2020 at 10:37 PM Ian Lance Taylor wrote: > On Fri, Jun 19, 2020 at 12:44 PM Brandon Bennett > wrote: > > > > I was playing around with a, probably not good, idea of what a rust-like > Return type would look like: https://go2goplay.golang.org/p/k0NKN9Q6Wc1 > > > > It seems when

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

2020-06-18 Thread 'Axel Wagner' via golang-nuts
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 >

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

2020-06-18 Thread 'Axel Wagner' via golang-nuts
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 < jesper.louis.ander...@gmail.com> wrote: > It is a type which cannot be inhabited by a term. These

Re: [go-nuts] [generics] some questions

2020-06-18 Thread 'Axel Wagner' via golang-nuts
On Thu, Jun 18, 2020, 13:21 T L wrote: > > > On Thursday, June 18, 2020 at 5:53:28 AM UTC-4, Axel Wagner wrote: >> >> >> >> On Thu, Jun 18, 2020, 11:28 T L wrote: >> >>> How to declare a generic functions which converting a slice with type Ta >>> to a slice with type Tb. Like >>> func

Re: [go-nuts] [generics] some questions

2020-06-18 Thread 'Axel Wagner' via golang-nuts
On Thu, Jun 18, 2020, 11:28 T L wrote: > How to declare a generic functions which converting a slice with type Ta > to a slice with type Tb. Like > func ConvertSlice(type Ta, Tb constraint)(ins []Ta) []Tb {...} > > How to constraint a type parameter must be of an interface type? > I don't think

Re: [go-nuts] [generics] is generics with constrain needed ?

2020-06-18 Thread 'Axel Wagner' via golang-nuts
I'd also say that converting between []Foo and []Stringer isn't actually definable in a type-safe manner: https://blog.merovius.de/2018/06/03/why-doesnt-go-have-variance-in.html Slices are writable as well as readable, so if you could convert []Foo to []Stringer you'd also have to say what happens

Re: [go-nuts] [generics] bring contracts back

2020-06-17 Thread 'Axel Wagner' via golang-nuts
Ah sorry, I misunderstood. Please disregard :) On Wed, Jun 17, 2020, 20:36 Axel Wagner wrote: > You can always combine multiple interface constraints: > > type ConstraintA(type A) interface { > Foo() A > } > > type ConstraintB(type B) interface { > Bar() B > } > > type

Re: [go-nuts] [generics] bring contracts back

2020-06-17 Thread 'Axel Wagner' via golang-nuts
You can always combine multiple interface constraints: type ConstraintA(type A) interface { Foo() A } type ConstraintB(type B) interface { Bar() B } type CombinedConstraint(type A, B) interface { (ConstraintA(A)) (ConstraintB(B)) } func F(type A, B CombinedConstraint(A, B))

Re: [go-nuts] [generics] Why is constraint optional?

2020-06-17 Thread 'Axel Wagner' via golang-nuts
On Wed, Jun 17, 2020 at 1:19 PM Hal wrote: > * the syntax defining generic function is verbose on purpose (type > keyword), not only for clarification, but also a remind of the cost and > complexity behind generics > I don't know where this idea is from, but it's not accurate. The type keyword

Re: [go-nuts] political fundraising on golang.org!

2020-06-15 Thread 'Axel Wagner' via golang-nuts
On Mon, Jun 15, 2020 at 1:04 PM Jon Reiter wrote: > Ok. I live in Singapore. Here is a statement from the Singapore Police > Force directly telling foreigners not to advocate for political causes or > risk being deported: > https://www.facebook.com/singaporepoliceforce/posts/10157358158324408

Re: [go-nuts] political fundraising on golang.org!

2020-06-15 Thread 'Axel Wagner' via golang-nuts
On Mon, Jun 15, 2020 at 11:56 AM Jon Reiter wrote: > It's not difficult to imagine banners like "free (some geographic place)" > or "remember (someone or some date)" causing severe problems. > It's also not difficult to imagine Orcs and wizarding schools and intergalactic star flight. Doesn't

Re: [go-nuts] political fundraising on golang.org!

2020-06-15 Thread 'Axel Wagner' via golang-nuts
Can you be more specific about how this is a real issue? Like, do you have precedent, where a banner-ad was the reason someone who linked to a page for unrelated reasons was prosecuted? Would be interesting to have some real cases so we get a clear picture of the threat here. Because to be clear,

Re: [go-nuts] political fundraising on golang.org!

2020-06-15 Thread 'Axel Wagner' via golang-nuts
I share link to golang.org all the time and I'd be willing to serve as a testcase for this. Feel free to report my alleged crimes to the police. Claiming that simply sharing a link to the Go page is "advocating for a foreign political cause" is clearly a bad-faith argument, so if you live in the

Re: [go-nuts] political fundraising on golang.org!

2020-06-14 Thread 'Axel Wagner' via golang-nuts
nt out the obvious. Some people (the > Go project) expressed support for a marginalized group and now, you and > others are trying to silence them. That's a political act. Which is why I > say, it's not about "if politics", it's "which politics". You are saying >

Re: [go-nuts] political fundraising on golang.org!

2020-06-14 Thread 'Axel Wagner' via golang-nuts
day and disagree on how > best to do so. It doesn’t have to be political at all. > > > > On Jun 14, 2020, at 4:43 PM, 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > > > >  > > Hi, > > > > the Go Team and the Go

Re: [go-nuts] political fundraising on golang.org!

2020-06-14 Thread 'Axel Wagner' via golang-nuts
's not about "if politics", it's "which politics". You are saying your political activism is okay, but theirs isn't. > > On Jun 14, 2020, at 4:43 PM, 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > >  > Hi, > > the Go Team and the

Re: [go-nuts] political fundraising on golang.org!

2020-06-14 Thread 'Axel Wagner' via golang-nuts
Hi, the Go Team and the Go Project are composed of people and expressing an opinion - *especially* a political one - is well within their right (If I was a conservative American I would wax poetically about the first amendment here). Let's not pretend this is about politics or not. This is about

Re: [go-nuts] The next layer of abstraction for Go development?

2020-06-13 Thread 'Axel Wagner' via golang-nuts
Maybe a dumb question but: Why would we *need* a standard framework? We're currently re-working this at my workplace and in the process, I've looked at both go-kit and micro. Ultimately, at least as far as I can tell, they don't seem to solve any of the problems I'm seeing, though. Both of them

Re: [go-nuts] What does the content about unsafe.Poiner in the compiler section in Go 1.15 release notes?

2020-06-12 Thread 'Axel Wagner' via golang-nuts
AIUI: The safety rules haven't changed. How the compiler interprets them has. Previously, it interpreted them so as to allow multiple chained conversions. Now it doesn't. On Fri, Jun 12, 2020 at 2:28 PM T L wrote: > > Package unsafe's safety rules >

Re: [go-nuts] Re: Why does Go transform os.Args[] with colons in this way (win32/x64)

2020-06-12 Thread 'Axel Wagner' via golang-nuts
I'd assume it has nothing to do with Go at all. You should try this with a minimal C program and look at the results. I assume it's something the shell is doing. On Fri, Jun 12, 2020 at 5:09 AM Russtopia wrote: > Ah, bad form posting before I tried it in a plain CMD.EXE context. > The args are

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

2020-06-11 Thread 'Axel Wagner' via golang-nuts
The Graph is clearly not linear. Another way to see this is to print out the ratio of time taken and i. If the cost is linear, you'd expect that ratio to be constant. When I run this code https://play.golang.org/p/v1JVQkOXnEH on my machine I get 1000 6.821361ms 6821.361 2000 27.229439ms

Re: [go-nuts] Re: what is the complexity of regexp.MustCompile()?

2020-06-09 Thread 'Axel Wagner' via golang-nuts
 >> Ray, only the discussion is exponential. >> >> On Mon, Jun 8, 2020 at 4:23 PM 'Axel Wagner' via golang-nuts < >> golang-nuts@googlegroups.com> wrote: >> >>> On Tue, Jun 9, 2020 at 12:48 AM Kurtis Rader >>> wrote: >>> >&

Re: [go-nuts] Re: what is the complexity of regexp.MustCompile()?

2020-06-08 Thread 'Axel Wagner' via golang-nuts
On Tue, Jun 9, 2020 at 12:48 AM Kurtis Rader wrote: > You're talking past each other. Robert is talking about limiting the > length of the regex, not the string(s) evaluated by the regex. > So am I. Note that e.g. a Code Search based on PCRE would break, even if you limit *both* (or rather, any

Re: [go-nuts] Re: what is the complexity of regexp.MustCompile()?

2020-06-08 Thread 'Axel Wagner' via golang-nuts
They don't have to be *arbitrarily* long. They actually can be quite short. 2^n is large, even for relatively small n. Again, I refer to the graphs in the blog post above. We are talking about input length of less than 100 characters to get CPU churn of *minutes*. That's not a huge limit for a

Re: [go-nuts] Re: what is the complexity of regexp.MustCompile()?

2020-06-08 Thread 'Axel Wagner' via golang-nuts
And that exact logic is what wouldn't work, if compilation or matching would be exponential, for example. Being able to say "as long as the inputs don't get astronomically long, the running time of the algorithm will be reasonable" is *exactly* the conclusion that a small complexity class gives

Re: [go-nuts] Re: what is the complexity of regexp.MustCompile()?

2020-06-08 Thread 'Axel Wagner' via golang-nuts
Oh, true, I overlooked that detail. But FTR, they clarify their question subsequently and specifically ask whether compilation is linear in expression size. No Must* in that clarification. On Mon, Jun 8, 2020 at 6:05 PM Thomas Bushnell, BSG wrote: > On Mon, Jun 8, 2020 at 12:02 PM Axel Wagner

Re: [go-nuts] Re: what is the complexity of regexp.MustCompile()?

2020-06-08 Thread 'Axel Wagner' via golang-nuts
sublinear in the input-size, then any attacker wanting to consume resources, must spent a proportional amount of their own resources. > > On Jun 8, 2020, at 8:27 AM, 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > >  > > > On Mon, Jun 8

Re: [go-nuts] Re: what is the complexity of regexp.MustCompile()?

2020-06-08 Thread 'Axel Wagner' via golang-nuts
level on a sufficiently large directory and >> it might run for days consuming TBs of memory - easily becoming a DOS >> attack point. So regardless of the complexity you need other constraints >> anyway. Build those in at the request handling level to avoid DOS and UX >> issues.

Re: [go-nuts] Re: what is the complexity of regexp.MustCompile()?

2020-06-08 Thread 'Axel Wagner' via golang-nuts
, that's on you). But it's definitely a relevant question to ask. > > On Jun 8, 2020, at 8:04 AM, 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > >  > On Mon, Jun 8, 2020 at 2:53 PM Robert Engels > wrote: > >> Attempting to prevent DOS at

Re: [go-nuts] Re: what is the complexity of regexp.MustCompile()?

2020-06-08 Thread 'Axel Wagner' via golang-nuts
rpus of a couple hundred characters. Regexp-based code search couldn't exist without carefully designing around algorithmic complexity. > > On Jun 8, 2020, at 7:40 AM, 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > >  > Hi Amnon, > > if you re

Re: [go-nuts] Re: what is the complexity of regexp.MustCompile()?

2020-06-08 Thread 'Axel Wagner' via golang-nuts
Hi Amnon, if you read the blog posts I linked above, you'll find examples of where we care very much. RE2 was developed for enabling regular expression search in a large source code corpus. In that scenario, the attacker controls both the regular expression and (to a degree) the text to be

Re: [go-nuts] Re: what is the complexity of regexp.MustCompile()?

2020-06-03 Thread 'Axel Wagner' via golang-nuts
Hi, I can very much recommend reading this list of blog posts by Russ Cox . They explain the theory behind all of this. And AIUI, yes, compilation should also be linear. The cost, notably, is that the regexp package actually can only compile actual regular

  1   2   3   4   5   6   >