On Thu, Dec 24, 2020 at 8:30 AM Martin Hanson
wrote:
> I write this from my understanding of the "Proposal selection criteria",
> which clearly states, that in order for a proposal to be accepted, it has
> to "address an important issue for many people".
>
It does. There is absolutely zero
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
On Thu, Dec 24, 2020 at 6:35 AM Artur Vianna wrote:
> Exposing the bytes would hurt the abstraction.
>
I strongly disagree with this. Exposing the bytes would improve the
abstraction, by making the transmission- and encoding method orthogonal.
And as I said, you can still provide just as
Lua `next` is a function that takes two arguments: a table and a key and
returns the another key (or nil). Unlike an iterator, it holds no
context. It is guaranteed that you will iterate over all keys if you
repeatedly call next as follows
k = next(t)
while k ~= nil do
k = next(t, k)
end
On Mon, Dec 21, 2020 at 5:54 PM Alexander Mills
wrote:
> this is a little irritating lol, i can get a signed url via:
>
> bucket := "bnk-photos"
> filename := "mypic3.json"
> method := "PUT"
> expires := time.Now().Add(time.Minute * 10)
>
> url, err := storage.SignedURL(bucket, filename, {
>
> If it's an object that already exists
no, sadly it's not, i need to generate the url to which i can upload the
image to, that url should be unsigned not signed.
that being said, a signed url might be fine.
On Thu, Dec 24, 2020 at 2:31 PM David Finkel wrote:
>
>
> On Mon, Dec 21, 2020 at 5:54
Hi there!
In my continued efforts to improve the performance of my Go Lua
implementation [1], I have reached a bottleneck which causes me a quandary.
Lua has a data structure which is called 'table', which is essentially a
hashmap. So far I have implemented it as a Go map, which works OK.
Thank you, Ian. Is there any desire to avoid introducing a new predefined
name? Is it going to be just an empty interface definition in one of the
core language modules similar to the following:
type any interface { }
If this is a case would be syntactically similar to have a function
(I am replying inline to make the context of my comment clear, although it
seems common practice to top-post in this forum - is there any guidance
about this?)
Arnaud
On Thursday, 24 December 2020 at 10:31:54 UTC kortschak wrote:
> You can also use the internal map implementation and make us
I will definitely explore your ideas, thanks for the insights. I'll let you
know how it turned out in the end :D
Thanks
On Thu, 24 Dec 2020, 06:59 Axel Wagner,
wrote:
> On Thu, Dec 24, 2020 at 6:35 AM Artur Vianna
> wrote:
>
>> Exposing the bytes would hurt the abstraction.
>>
>
> I strongly
I did have a look at hash/maphash, but I didn't think it was the right
shaped API for what I am doing. In short, I would have to contrive to
provide words to the package as byte slices, which then would turn them
back into words under the hood. That feels like a superfluous round trip,
given
@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
On Thu, Dec 24, 2020 at 11:19 AM Arnaud Delobelle wrote:
> Does that sound like a sensible approach? I.e. is it safe enough to use
> the go:linkname directive, and do those seem like the right functions to
> call to obtain a good hash?
>
It is probably better to use hash/maphash, if you can.
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
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
On Thursday, 24 December 2020 at 14:31:22 UTC Jan Mercl wrote:
> On Thu, Dec 24, 2020 at 3:12 PM Arnaud Delobelle
> wrote:
> > That's interesting, thanks. Although I don't think it fits my use case
> because I need something stronger than an iterator: a function that given a
> table and a
Simplicity is not an easy topic to discuss. Personally, I would like to
define simplicity in the source code in terms of complexity. In the code,
complexity comes from the irreversibility of our design decisions.
Go has no need for generics on the receiver side. It is possible to define
ad-hoc
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
I agree.
A lot of Gonum code would be greatly simplified with the availability
of generics, particularly the linear algebra part. The graph packages
would be richer and we could do more things with tensor-like
operations.
On Wed, 2020-12-23 at 23:54 -0800, Marcin Romaszewicz wrote:
> Those are
You can also use the internal map implementation and make us of the
runtime's map iterator. This is relatively straightforward at the cost
of vigilance for changes in the runtime.
Here is an example (note that yo need a .S file as well to get the
go:linkname magic to work).
I second this. Linear Algebra code would dramatically benefit from
generics. Code would become much more simpler if you could write Tensor and
Matrix code independent of the type of the numeric values used by those
types.
Practical applications are graphics libraries, geography applications
On Thu, Dec 24, 2020, 1:18 AM Martin Hanson
wrote:
> I'm sorry, but this is not real life problems. This is exactly the problem
> with this proposal. It's based on nothing but small theoretical examples.
>
Sorry, I don't understand.
Here are some of the example applications which Ian mentions
Protobufs is what you want. Since you have the schema on server and client the
amount of data dictionary overhead per message is minimal - essentially numeric
tags and the raw data.
> On Dec 24, 2020, at 8:21 AM, Artur Vianna wrote:
>
>
> I will definitely explore your ideas, thanks for
>
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
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:
I think theoretically, you might be able to optimize it away (at least in
the overwhelming majority of use-cases) by storing a couple of
`*reflect.MapIter` for the last used tables in the context of the VM and
then check, when `next` is called, if the key passed is the one it's
currently at. But I
Dnia 2020-12-24, o godz. 06:19:53
Arnaud Delobelle napisał(a):
> I did have a look at hash/maphash, but I didn't think it was the right
> shaped API for what I am doing.
Do not be afraid to just "steal" runtime implementation and tinker with it to
get at desired properties.
On Thu, Dec 24, 2020 at 4:08 PM Arnaud Delobelle wrote:
> The order is undefined but stable (provided you don't insert new values), and
> accessible via the `next` function. Here is an example:
Quoting from the provided link:
next (table [, index])
Allows a program to traverse all
For my part, I see some value in maintaining a source of example solutions
to problems that generics could solve. Since I was not aware of any
resource that attempts to gather together several example implementations
in one place (and couldn't find one after a couple minutes of searching), I
On Thu, Dec 24, 2020 at 4:04 AM LeoY wrote:
>
> Thank you, Ian. Is there any desire to avoid introducing a new predefined
> name? Is it going to be just an empty interface definition in one of the core
> language modules similar to the following:
>
> type any interface { }
>
> If this is a case
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
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
On Thu, Dec 24, 2020 at 3:12 PM Arnaud Delobelle wrote:
> That's interesting, thanks. Although I don't think it fits my use case
> because I need something stronger than an iterator: a function that given a
> table and a key returns the next key in the table (as this is a public API
> that
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
> Tasteless attempt at humour.
Our collective taste is ruined by the
anosmia of a contemporary disease.
Anthony
--
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
Indeed. I'm working on a boolean logic package that has a number of different
bitfield oriented backends, all of which will have a lot of very needlessly
repetitive code without generics. If generics weren't coming "soon" I'd
consider writing a generator to build it, but generics are the much
36 matches
Mail list logo
