Aliased generics. For a better future

[dlsniper]

No description provided.

[StabbyCutyou]

More evidence of the community driven nature of package generics!

I'll review the code later tonight, but I love the gumption!

[StabbyCutyou]

So, I'm still in the process of reviewing your contributions, but I will say that it seems your changes have made the tests take so many hours to complete, that they simply time out.

Because performance is of the utmost concern, I'll need to look into where the degradation is coming from. Go is all about performance, and as the author of package generics, I cannot let the theoretical millions of gophers who rely on this package down.

[krisnova]

Is this the most robust solution for unique build code?

I am wondering if we could implement some auto-generating system to solve this problem moving forward? I opened up #20 to take the discussion forward

[StabbyCutyou]

This is a good question - i'd invite the opener of this PR into the discussion to get his thoughts as well.

[dlsniper]

The build constraint will allow building for future, at least until the Go Team will see the errors of their way and adopt this excellent generics solution as a solution for generics in Go.

[dlsniper]

I've read on the Internet that if I close and reopen the PR Travis will try again

[dlsniper]

Dear Maintainer,

Seeing how it's of utmost important to ensure widespread usability and testability of this package,
I took the liberty to further add to the package testing suite the missing Go versions.

I hope that my actions will be rewarded with some of that sweet sweet acceptance into this select club of contributors as I'm trying to make these changes available for everyone.

Please let me know if these changes are now up to the high standards imposed by this project and if not, how I can improve my work so that this becomes part of the Source.

Thank you.

Yours truly,
@dlsniper

[StabbyCutyou]

An additional question for the opener of the PR:

With the current build tag solution, will the go1.9 build continue to be chosen for 1.10, 1.11, 1.12, etc?

Or as commenter K Nova suggests, do we need a more robust solution?

Excited to see where this PR goes! A backwards compatible but future-thinking change is exactly the kind of fresh thinking lifeblood that package generics needs to stay alive in this competitive climate!