Ian Lance Taylor schrieb am Dienstag, 23. März 2021 um 23:22:51 UTC+1:
> On Tue, Mar 23, 2021 at 3:19 PM atd...@gmail.com <atd...@gmail.com>
> wrote:
> >
> > Since, we also know the type of v, It would be infered from it.
> >
> > There is no variance, no dependent type... Meaning that the type of a Go
> variable does not change.
> > So the constraints do not change midway through the program, including
> type names/definitions.
> >
> > It does however require to have something that resemble a type
> definition beforehand.
> > A type parameter definition.
>
> In some cases it can be inferred.
But even if it can be inferred it should be possible to annotate the type I
do expect,
to improve local readiblity and compile time error message quality:
I assume that "x" is later used in a context requiring the type to be "int":
x := Min(someFunc(foo), someFunc(bar))
Here i can use:
var x int = Min(someFunc(foo), someFunc(bar)))
but using
x := Min[int]( someFunc(foo), someFunc(bar)))
The three version yield different error message, if the called function
"someFunc()" return a float instead of the expected int.
But what about cases where it
> can't? And what if I want to write
>
> // IntMin is a function with type func(int, int) int.
> var IntMin = Min[int]
>
?
>
> The constraints don't change midway through a program, but in your
> example the meaning of T does change.
>
>
hmmm... if all I need throughout my whole package is one binding e.g. to
"int",
or to the type parameter "MyParameterType" my function use for themselves
it may get teadious to
repeat the [MyParameter] all over the place.
Type inferences helps, but weakens the quality of error messages.
So please always allow for a explicit type parameter annotation even if
inference is possible.
(And doing so in a more global location may improve simplicity a lot;-)
Martin
> Ian
>
>
> > On Tuesday, March 23, 2021 at 10:41:15 PM UTC+1 Ian Lance Taylor wrote:
> >>
> >> On Tue, Mar 23, 2021 at 2:17 PM atd...@gmail.com <atd...@gmail.com>
> wrote:
> >> >
> >> > Quick question...
> >> >
> >> > Why do we need brackets to define a parametered function, struct
> etc...?
> >> >
> >> > Why not change Go kinds to accept either a type (would produce a
> regular, function, structs, etc) or a new type parameter object that would
> implement the constraints (would produce a generic function definition)
> >> >
> >> > for instance,
> >> >
> >> > type parameter T
> >> >
> >> > // [...] some way to add constraint to T
> >> >
> >> > func Max(v T) T{...}
> >> >
> >> > What are the brackets for? Just an idea.
> >>
> >> Each call to Max can use a different value for T. We can call
> >> Max[int] and Max[string]. How would we do that with this notation?
> >>
> >> A type parameter really is a parameter to the function. Making it
> >> syntactically similar to other non-type parameters seems like a good
> >> idea to me.
> >>
> >> 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...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/5713130f-20c7-4b70-ba8f-2e9be22cb9c9n%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/ba6f07e2-f89f-4d59-9f10-e0e2fcea004en%40googlegroups.com.
