On Sun, Feb 2, 2020 at 7:08 PM Steve Roth wrote:
>
> What I'm suggesting may be covered by generics if and when they ever happen,
> but considering that generics are a breaking change and are years away at
> best, they are not relevant to the evaluation of a small, backward-compatible
>
what part of GOPATH that confuse you ?
Pada Minggu, 02 Februari 2020 21.45.22 UTC+7, Amnon Baron Cohen menulis:
>
> Kill GOPATH!
>
> It was a terrible idea. Thankfully no longer needed.
> But it causes no end of confusion.
>
--
You received this message because you are subscribed to the Google
On Sun, Feb 2, 2020 at 7:52 PM Steve Roth wrote:
> Your assertion that "using an enum as a slice index would NEVER be safe"
> seems rather extreme to me. It may be true in an academic sense, but in
> pragmatic engineering, enums defined using iota are not sparse and using
> them as slice
On Sun, Feb 2, 2020 at 8:52 PM Steve Roth wrote:
>
> Your assertion that "using an enum as a slice index would NEVER be safe"
> seems rather extreme to me. It may be true in an academic sense, but in
> pragmatic engineering, enums defined using iota are not sparse and using them
> as slice
Your assertion that "using an enum as a slice index would NEVER be safe"
seems rather extreme to me. It may be true in an academic sense, but in
pragmatic engineering, enums defined using iota are not sparse and using
them as slice indices would generally be quite safe. Yes, this is safety
by
*generics :)
> On Feb 2, 2020, at 9:27 PM, Robert Engels wrote:
>
>
> I think the major difference is that by using EventID as a constrained type,
> you are then attempting to constrain index values - for which there are no
> constraints other than slice length.
>
> Similarly, using an
I think the major difference is that by using EventID as a constrained type,
you are then attempting to constrain index values - for which there are no
constraints other than slice length.
Similarly, using an enum as a slice index would NEVER be safe. Enums are
sparse. Slices are contiguous.
Hi, Robert,
Thanks for the quick replies. Let me address each of your points:
"Slice indexes are ints" is clearly true in the current language
definition. From a pure language standpoint, one might assert that any
index type other than plain int requires a map. However, if one has a data
One last point, if you are interested in type safety, why not create simple
structs like EventList to encapsulate the indexing, etc. Trivial and can be
done today.
> On Feb 2, 2020, at 8:28 PM, Robert Engels wrote:
>
>
> Also, what you are asking for I believe is covered by generics.
>
Also, what you are asking for I believe is covered by generics.
> On Feb 2, 2020, at 8:17 PM, Steve Roth wrote:
>
>
> Oh, please, Robert. No need to be condescending. I know perfectly well how
> to use the value when that's what I want. Often it is not. The examples
> that I cited are
It not being condescending. Your code is not correct. It is not an eventID - it
is an index (an int). Slice indexes are ints. If you want a typed key (other
than int) you need a map (or variant).
> On Feb 2, 2020, at 8:17 PM, Steve Roth wrote:
>
>
> Oh, please, Robert. No need to be
Oh, please, Robert. No need to be condescending. I know perfectly well
how to use the value when that's what I want. Often it is not. The
examples that I cited are such a case: we are adding the IDs of the events
— the indices of the slice — to the person.Events field. If you don't like
my
You are using range incorrectly - you are using the index not the value.
See https://tour.golang.org/moretypes/16
> On Feb 2, 2020, at 7:39 PM, Steve Roth wrote:
>
>
> Greetings,
>
> I'm considering submitting a proposal for a language change, and would like
> some informal feedback on
Greetings,
I'm considering submitting a proposal for a language change, and would like
some informal feedback on the idea before engaging the formal process. The
idea being proposed here is intended to improve type safety by removing the
need for some error-prone type casting. It is a backward
On Sunday, February 2, 2020 at 3:16:44 AM UTC+1, Randall O'Reilly wrote:
>
> Apologies for being really slow on the uptake here, but I’m just now
> realizing that the master plan is to actually get rid of the GOPATH mode!
> Is there any chance of possibly retaining it? Is it too much work to
Kill GOPATH!
It was a terrible idea. Thankfully no longer needed.
But it causes no end of confusion.
--
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
to
Dnia 2020-02-01, o godz. 18:16:11
Randall O'Reilly napisał(a):
> But I really like GOPATH! See: https://divan.dev/posts/gopath/ for some
> similar sentiments.
I concur!
See also https://github.com/golang/go/issues/26640, recently reopened,
2020-02-01 22:50:27 időpontban Tamás Gulácsi a
On Saturday, 25 January 2020 22:16:26 UTC, Eric Raymond wrote:
>
>
> And that's the insight that led be to the extension I proposed. I asked
> myself what the most natural way to pass out a soft close might be.
>
>
Suppose we continue with the idea of an iterator being a goroutine which
Thanks Michael!
>
>
--
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
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
19 matches
Mail list logo
