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 <st...@rothskeller.net> 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 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 > example, take a look through the standard library code: you'll find a great > many instances of range loops using only the index. > > Regards, > Steve > > >> On Sun, Feb 2, 2020 at 5:56 PM Robert Engels <reng...@ix.netcom.com> wrote: >> 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 <st...@rothskeller.net> wrote: >>>> >>> >>> 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 compatible change. >>> >>> Consider a body of code that works with people and events. Both are >>> identified with integer IDs; in order to prevent them being used in the >>> wrong contexts, they are given specific integer types: >>> type EventID int >>> type PersonID int >>> Assume also that people have lists of events they attend: >>> type Person struct { >>> Events []EventID >>> } >>> The code maintains slices of each type: >>> var events []*Event >>> var people []*Person >>> When indexing into those slices, one can use the appropriate ID type: >>> var eventID EventID = 3 >>> println(events[eventID]) >>> However, iterating over these slices requires casting in the current Go >>> specification: >>> for eventID := range events { >>> // eventID here has type int, not type EventID >>> person.Events = append(person.Events, eventID) // compile error, wrong type >>> person.Events = append(person.Events, EventID(eventID)) // cast required >>> } >>> In cases where the event ID needs to be used inside the loop, it has lost >>> its type safety. It has to be casted back to the type it is supposed to >>> have. And that casting is error-prone; I could easily cast it to PersonID >>> by mistake. This seems to be a noteworthy gap in type safety. >>> >>> My proposal is to allow this construction: >>> var eventID EventID >>> for eventID = range events { >>> // eventID here has type EventID >>> person.Events = append(person.Events, eventID) // accepted by compiler >>> } >>> Phrased more formally: a slice range operator can be assigned to a variable >>> of any integer-derived type, not just "int". If this were done, >>> error-prone casting could be avoided. >>> >>> Admittedly, there is still room for error here, since it would be possible >>> to write >>> var eventID PersonID >>> for eventID = range events { >>> // eventID here has the wrong type PersonID >>> person.Events = append(person.Events, eventID) // compile error, wrong type >>> } >>> However, this error seems far less likely that a mistaken cast. And since >>> there's no expectation that casts should be needed, the compiler error >>> would cause greater scrutiny leading to fixing the real problem. (In any >>> case, I don't wish to propose the (much larger and more impactful) change >>> of having slices with typed indices.) >>> >>> I believe this proposal would significantly improve type safety in programs >>> that work with multiple integer-derived types (such as most anything >>> working with a relational database that prefers integer primary keys). I >>> also believe it is backward compatible since it does not change the >>> semantic of any existing code; it just adds a semantic to code that >>> currently would not compile. >>> >>> I solicit the community's feedback. Should this proposal be formally >>> submitted? >>> >>> Regards, >>> Steve >>> >>> -- >>> 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 >>> https://groups.google.com/d/msgid/golang-nuts/CAAnpqKHS%3D2z0ZbNVSrULXLLGz%3DhAqpmrsLieciFu8L6%3DAn%3DLHA%40mail.gmail.com. > > -- > 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 > https://groups.google.com/d/msgid/golang-nuts/CAAnpqKEEOPicjwD%3Dmy08ORMzOwFiMFy4F%3DG3L9bdLFfbbsnHWA%40mail.gmail.com. -- 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 https://groups.google.com/d/msgid/golang-nuts/BE40614F-17E0-42BE-9B5F-7C854004412B%40ix.netcom.com.
