Nevermind, I forgot about function return values.
Difficult to infer them without specifying them, isn'it?
Sorry... should have thought better.
On Wednesday, March 24, 2021 at 12:23:12 AM UTC+1 atd...@gmail.com wrote:
> Mmmh, :/ depends. What is the type of IntMin for the compiler in your
> example? The same as Min?
>
> If not, it is basically defining a regular function out of a generic
> function definition.
> So it is merely about constraining the type parameter further to be of
> specific type int.
>
> A simple closure would be a sensible way to deal with it easily. In
> general, one would define a general closure function with new type
> parameters that have aditional constraints.
>
> Trying to see type parameters more like concrete types and interface
> types, just with different constraints enforced at compile-time than those
> of types and interface types.
> Could make brackets redundant.
> On Tuesday, March 23, 2021 at 11:22:51 PM UTC+1 Ian Lance Taylor wrote:
>
>> 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 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.
>>
>> 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/23765669-8548-4977-abd9-fe5b183f4461n%40googlegroups.com.
