Yes, and... (just in case someone else comes across this thread wondering
in the distant future) ,
func(v T) T is not too big a problem but func(v T) R
If the function body has cases, i.e. flow sensitive, that's where the
brackets are mandatory to make the inference more straightforwardly
decidable.
Unfortunately, that's what happens if returns are created by unboxing an
interface for instance. We introduce variance.
It might be solvable/partially solvable via constraint-propagation /
type-flow analysis or we can be wise and just constrain return values to be
of a specific type but then brackets are needed.
On Wed, Mar 24, 2021, 9:28 AM Markus Heukelom <markus.heuke...@gain.pro>
wrote:
> I agree here that there is a lot of repetition in the function definitions
> of let's say a generic math package:
>
> types Numbers { type float32,float64, }
>
> func Abs[T Floats](a T) T {}
> func Sin[T Floats](a T) T {}
> func Cos[T Floats](a T) T {}
>
> etc. (50 orso more?)
>
> It feels a bit redundant and "noisy" to the eye. I think in practice, any
> good generic packages will only use maybe one or two type parameters
> constrainsts (interfaces), and likewise most types (functions) will use
> very similar if not the same type parameters lists.
>
> So I tried to come up with a solution similar to yours by predefining T
> which could then be directly. But as Ian illustrated there's issues that
> are not naturally solved. So I agree that the current proposal is simpler
> (with the downside of being a bit "noisier" wrt such a proposal).
>
> Another solution that comes to mind would be to allow to some sort of
> grouping structure:
>
> generic [T Numbers] {
> func Abs(a T) T {}
> func Sin(a T) T {}
> func Cos(a T) T {}
> }
>
> This would give all types within the group the same type parameters list.
> The grouping my also be useful for documentation. Obvious downside is the
> extra level of indentation on package level (although it nicely separates
> the generic types from concrete types, so maybe just getting used to).
> Another downside is the introduction of the "generic" keyword.
>
> -Markus
>
>
> On Tuesday, March 23, 2021 at 10:16:44 PM UTC+1 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.
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/x3ZffZXHMyA/unsubscribe.
> To unsubscribe from this group and all its topics, 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/b802e7fe-4f72-4804-8c23-ea55ac4a5de0n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/b802e7fe-4f72-4804-8c23-ea55ac4a5de0n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAJcwgVrw5O%2B_%3D9yxg%3DBVr25gXUrGPS6GkxX7mO3TLOiNbxS3qw%40mail.gmail.com.
