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 > <https://groups.google.com/d/msgid/golang-nuts/CAAnpqKHS%3D2z0ZbNVSrULXLLGz%3DhAqpmrsLieciFu8L6%3DAn%3DLHA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- 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.
