>> Fair enough.
>
>It could be a first step (genrics only in the stdlib) before opening
>generics to everybody.
This stdlib trial approach might allow a spec to mature without the
compatibility promise? Is there a danger that it evolves to favour implementers
over readers?
Should support for
On 01-01-2021, Ian Lance Taylor wrote:
> On Fri, Jan 1, 2021 at 12:40 PM robert engels wrote:
>>
>> I was thinking more of an internal api - maybe stdlib authors only - writing
>> code similar to map.go to create an alternate map type, and allow selecting
>> of that map type in the make() call.
On Fri, Jan 1, 2021 at 2:16 PM Axel Wagner
wrote:
> Hi,
>
> On Fri, Jan 1, 2021 at 1:41 PM Markus Heukelom
> wrote:
>
>> One thing that comes to mind that is not supported by the current
>> proposal is the ability to express that T must be (any) struct.
>>
> […]
>>
> Another example is where you
Hi,
On Fri, Jan 1, 2021 at 1:41 PM Markus Heukelom
wrote:
> One thing that comes to mind that is not supported by the current proposal
> is the ability to express that T must be (any) struct.
>
[…]
>
Another example is where you write a library that creates an RPC service
> from any function tha
>> On Thursday, December 31, 2020 at 11:27:06 AM UTC+1
axel.wa...@googlemail.com wrote:
>> I don't think the current draft lets us express very powerful
invariants. And while I wouldn't really advocate to make that a target, I
think it would be interesting to see more discussion of this area -
On 31-12-2020, Alex Besogonov wrote:
> I had a couple of reflective helpers that did this work through reflection,
> but it was not clean and had broken more than once during refactorings. I
> actually gave up on Go for this project and rewrote it in Python, resulting
> in 10x (ten times) less
On Wednesday, December 23, 2020 at 10:16:00 PM UTC-8 Martin Hanson wrote:
> If all we're presented are these small theoretical examples of sorting
> lists, etc., then clearly this is nothing but hype that needs to go
> away.
>
My personal example: ordered containers. My code works with physical
Hi,
On Thu, Dec 31, 2020 at 8:59 AM wilk wrote:
> If 95% of generics are collections the current draft is overkill.
> What about a simplified version with only one generic type (like we do
> with interface{}), without constraint as long as it can compile ?
>
• "Only one generic type" means you
On 30-12-2020, robert engels wrote:
>
> --Apple-Mail=_053BD88E-EE7F-423A-AE3D-712B500390F8
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain; charset="UTF-8"
>
> Agreed.
>
> I had proposed a different approach, where the built-in map and slice could=
> have alternative imple
Here is another example.
I haven’t worked out the details yet, but I envision that I can avoid
generating this QuorumSpec interface in our Gorums framework:
https://github.com/relab/gorums/blob/master/cmd/protoc-gen-gorums/dev/zorums_qspec_gorums.pb.go
And instead use generics... I hope that this
What's the Big-O on determining whether N functions are
a/ identical,
b/ similar but expressing potentially unique behavior,
c/ subtly varied.
identical, assuming x and y have the same type:
func (t *T) fX() bool {
return t.x == t.z
}
func (t *T) fY() bool {
return t.y ==
On Fri, 2020-12-25 at 18:11 +0100, Martin Hanson wrote:
>
> What are you on about!? This is my second post on this list, and even
> though both are about
> generics, they are adequately different to be kept about otherwise it
> becomes a big mess.
Some mailers do not properly handle headers neces
> You are repeatedly starting new threads, keeping the same subject as already
> existing ones.
> Don't do that please, if you respond to a certain topic keep the thread
> intact.
>
> That way all the conversation is in a single place.
What are you on about!? This is my second post on this lis
You are repeatedly starting new threads, keeping the same subject as already
existing ones.
Don't do that please, if you respond to a certain topic keep the thread intact.
That way all the conversation is in a single place.
--
You received this message because you are subscribed to the Google G
Hi,
This is not a real life problem but I think this is a real life problem in
the software industry and a problem for developers. I saw this for Swift
(this is just an example):
https://github.com/raywenderlich/swift-algorithm-club
I was always wondering if Go can have something like this. One
On Thu, Dec 24, 2020 at 6:39 AM Martin Hanson
wrote:
>
> @Ian Lance Taylor, I feel I must apologize to you. I have just hunted
> down every single mailing list post from you regarding the generics
> issues and I have found that you have been extremely balanced and very
> much protecting the Go phi
I do not have an example implemented with generics, but I do have examples
that could use them. My renderview - https://github.com/TheGrum/renderview
; in particular this
file: https://github.com/TheGrum/renderview/blob/master/renderparameter.go
and my still unpublished audio library, visible i
>
I have been arguing passionately against adding generics to Go because
I truly believe that it is going against the simplicity of Go and the
philosophy behind the design of Go.
How about providing some evidence to back such an assertion, in the same
spirit of asking others to provide justi
I have found this extremely useful (was posted on GitHub) and I post
this for any latecomers to this thread some time in the future:
https://github.com/golang/go/wiki/ExperienceReports#generics
Especially this document:
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX
@Ian Lance Taylor, I feel I must apologize to you. I have just hunted
down every single mailing list post from you regarding the generics
issues and I have found that you have been extremely balanced and very
much protecting the Go philosophy and wanting to avoid any added
complexity etc.
I am sor
On 24-12-2020, Sebastien Binet wrote:
> This is a multi-part message in MIME format.
>
> --b1_GrUsz2qka8Vf9CMQa2ukahUpPKrwyxBqPmoLYzM
> Content-Type: text/plain; charset="UTF-8"
>
> Like every other feature from Go.
> Think channels and goroutines.
> Or the reflect package. Or the unsafe one.
> Or
Like every other feature from Go.
Think channels and goroutines.
Or the reflect package. Or the unsafe one.
Or big large fat interfaces.
Or the empty interface.
Original Message
On Dec 24, 2020, 11:42, wilk wrote:
> On 24-12-2020, Marcin Romaszewicz wrote:
>
>> Generics would al
On 24-12-2020, Marcin Romaszewicz wrote:
> Generics would allow for writing less code, and re-using it more. As long
> as it doesn't complicate the base language, why not? You don't have to use
> them :)
The only problem with Generics is when it will be abused. Maybe never,
how to know ?
The cur
On 24-12-2020, Igor Cananea wrote:
> --9cfe9505b7311862
> Content-Type: text/plain; charset="UTF-8"
>
> While the example of ReverseSlice doesn't appear in my work experience, the
> concept of writing functions for slices independent of type is pretty
> common for me.
I like a lot how
24 matches
Mail list logo
