On Aug 20, 2020, at 5:27 PM, Ian Lance Taylor wrote:
>
> After many discussions and reading many comments, we plan to move
> forward with some changes and clarifications to the generics design
> draft.
>
> 1.
>
> We’re going to settle on square brackets for the generics syntax.
> We’re going to
On Thu, Aug 20, 2020 at 10:53 PM Kurtis Rader wrote:
> Isn't your example just a case of confusing a nil interface with a nil
> value inside a generic interface? How does requiring writing it as `func
> f() interface{} {` make the behavior any clearer?
>
And the, possibly canonical, discussion a
On Thu, Aug 20, 2020 at 10:40 PM burak serdar wrote:
> What worries me is code like this:
>
> func f() any {
>int *i
> return i
> }
>
> func main() {
>if f()==nil {
> ...
>}
> }
>
> Use of "any" makes it look like f returns an *int and f() is nil, but
> it is not, because "any"
On Thu, Aug 20, 2020 at 10:54 PM Ian Lance Taylor wrote:
>
> On Thu, Aug 20, 2020 at 8:52 PM burak serdar wrote:
> >
> > On Thu, Aug 20, 2020 at 8:22 PM Jan Mercl <0xj...@gmail.com> wrote:
> > >
> > > On Fri, Aug 21, 2020 at 2:28 AM Ian Lance Taylor wrote:
> > >
> > > > To simplify the common ca
On Thu, Aug 20, 2020 at 8:28 PM jimmy frasche wrote:
>
> To clarify on the type switches, would it have to be used like this:
>
> type C interface {
> type X, Y
> }
>
> func f(x X) X {
> return x
> }
>
> func g[T C](v T) T {
> switch v {
> case X:
> // to use v as an X
> // we must
On Thu, Aug 20, 2020 at 8:52 PM burak serdar wrote:
>
> On Thu, Aug 20, 2020 at 8:22 PM Jan Mercl <0xj...@gmail.com> wrote:
> >
> > On Fri, Aug 21, 2020 at 2:28 AM Ian Lance Taylor wrote:
> >
> > > To simplify the common case of a type parameter that has
> > > no constraints, we will introduce a
On Thu, Aug 20, 2020 at 8:22 PM Jan Mercl <0xj...@gmail.com> wrote:
>
> On Fri, Aug 21, 2020 at 2:28 AM Ian Lance Taylor wrote:
>
> > To simplify the common case of a type parameter that has
> > no constraints, we will introduce a new predeclared identifier “any”
> > as an alias for “interface{}”.
To clarify on the type switches, would it have to be used like this:
type C interface {
type X, Y
}
func f(x X) X {
return x
}
func g[T C](v T) T {
switch v {
case X:
// to use v as an X
// we must convert
x0 := X(v)
x1 := f(x0)
// to use x1 as a T
// we must conv
I like it. Well done.
> On Aug 20, 2020, at 9:22 PM, Jan Mercl <0xj...@gmail.com> wrote:
>
> On Fri, Aug 21, 2020 at 2:28 AM Ian Lance Taylor wrote:
>
>> To simplify the common case of a type parameter that has
>> no constraints, we will introduce a new predeclared identifier “any”
>> as an a
On Fri, Aug 21, 2020 at 2:28 AM Ian Lance Taylor wrote:
> To simplify the common case of a type parameter that has
> no constraints, we will introduce a new predeclared identifier “any”
> as an alias for “interface{}”.
Anyone can write the declaration
type any = interface{}
today and p
On Aug 20, 2020, at 20:27, Ian Lance Taylor wrote:
>
> 1.
>
> We’re going to settle on square brackets for the generics syntax.
> We’re going to drop the “type” keyword before type parameters, as
> using square brackets is sufficient to distinguish the type parameter
> list from the ordinary par
After many discussions and reading many comments, we plan to move
forward with some changes and clarifications to the generics design
draft.
1.
We’re going to settle on square brackets for the generics syntax.
We’re going to drop the “type” keyword before type parameters, as
using square brackets
In my application I store a map of all my templates
(`map[string]*template.Template`) in an `ApplicationEngine` struct, which
is my application framework instance. I am currently using the standard
`context.Context` to pass request scoped values between my middlewares and
handlers. I need a way
Hello,
This is a small Go IDE for the Android platform. It's side project I
started long ago. Since I haven't had much time to work on this, I've
decided to release it, maybe someone will pick it up.
https://github.com/theseafaringturtle/goforandroid
It supports cloning Git projects, but it do
Hello everyone,
I'll try the methods mentioned above.
Thanks for your replying.
Max
--
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...@googl
15 matches
Mail list logo