Forget about it. Does not work. Can't avoid having to constrain types. An
algorithm for value types would not be so easily usable with pointer types,
at the very least because of nil checks.
And, although it might not be a problem, if we ever have type list
interfaces, or even simple multi-para
Just coming back to this quickly, although it is unlikely to change
anything at this stage, but, re. a transform function, instead of using
parametric polymorphism, I think it is possible to do it with interface
arguments and to a greater extent, type lists interface arguments if we
have access
Looking briefly, seems interesting but slightly different. It seems that
the intent described in the paper is to endorse full blown functions as a
replacement to import statements.
It is useful insofar that it could rationalize the use of build constraints
in Go. But it is too expressive in tha
On Wed, Jan 20, 2021 at 4:22 PM atd...@gmail.com wrote:
> It' has probably been discussed somewhere but I am curious about what
> might have been the issues when considering an implementation of generics
> that would parameterized packages?
>
>
You can take a look at Standard ML / Ocaml "functors
Hello,
It' has probably been discussed somewhere but I am curious about what might
have been the issues when considering an implementation of generics that
would parameterized packages?
The rationale being that usually, packages have a non-mutable interface for
the user and are the ompilation
