On Tuesday, October 6, 2020 at 1:54:16 PM UTC-4 Ian Lance Taylor wrote:
> On Tue, Oct 6, 2020 at 10:28 AM tapi...@gmail.com
> wrote:
> >
> > IMO, the bar function is cleaner and more readable than the foo
> function.
> > How do you think?
> >
> > func foo() {
> > if vs := f(); len(vs)
On Tue, Oct 6, 2020 at 10:28 AM tapi...@gmail.com wrote:
>
> IMO, the bar function is cleaner and more readable than the foo function.
> How do you think?
>
> func foo() {
> if vs := f(); len(vs) == 0 {
> } else {
> for _, v := range vs {
> }
>
On Tue, Oct 6, 2020 at 6:32 AM Markus Heukelom wrote:
>
> It appears to me the current proposal does not allow you to write a function
> that sorts an array of any size:
>
> func SortArray[T comparable](array [??]T, less func(a, b T) bool) [??]T {}
>
> Is it correct that this is not possible? Or
IMO opinion the answer is nicely demonstrated in the alignment of sone of
the closing braces you've chosen in the func bar example.
On Tue, Oct 6, 2020, 19:28 tapi...@gmail.com wrote:
> IMO, the bar function is cleaner and more readable than the foo function.
> How do you think?
>
> func
IMO, the bar function is cleaner and more readable than the foo function.
How do you think?
func foo() {
if vs := f(); len(vs) == 0 {
} else {
for _, v := range vs {
}
}
if vs := f(); len(vs) == 0 {
} else {
This would require something similar to rust's const generics. IIRC, that's
not on the table with the initial draft
On Tuesday, October 6, 2020 at 3:31:46 PM UTC+2 markus@gain.pro wrote:
> It appears to me the current proposal does not allow you to write a
> function that sorts an array of
Hey Gophers,
I’d like to share our new auto-generated database client for Go – it’s
focused on complete type-safety wherever possible and makes querying for
complex data and relations a delight :)
I’m currently experimenting with syntax and features, so any feedback would
be highly
A transpiler that will implement index operator methods will be very
appealing at first. But it won't be long before general operator
overloading will be added to its feature set and the result is splitting Go
to a different language...
The question is, what is best to the go community in the
Dnia 2020-10-06, o godz. 00:56:38
Raanan Hadar napisał(a):
> To a gonum user, this proposal is about a 20% improvement and nothing to run
> home about.
> To a matlab/python programmer, this solves about 80% of their problems and
> combining this
> with the other benefits of Go is enough to
It appears to me the current proposal does not allow you to write a
function that sorts an array of any size:
func SortArray[T comparable](array [??]T, less func(a, b T) bool) [??]T {}
Is it correct that this is not possible? Or is this expressed differently?
To clarify, I am seeking for
On Mon, Oct 5, 2020 at 3:03 PM 'Bryan C. Mills' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
>
> The core of the problem is that `assert` functions generally *cannot* provide
> enough context to produce useful test failures
>
Lets start with saying that I think this is a valid criticism.
Although it does not solve things 100%, it does solve the heart of the
problem for me at least:
There is a mixture of index operators with functional operators in the
syntax:
The [] operator gives the reader the 'where' context
i think this looks nice but realistically only cleans up v simple cases. a
lot of the very-verbose-and-not-so-elegant-looking multidimensional math
stuff looks "worse" than other languages because go doesn't have operator
overloading. it is not clear to me this improves syntax too much in
13 matches
Mail list logo
