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 <reng...@ix.netcom.com> wrote: > > > Also, what you are asking for I believe is covered by generics. > >>> 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/75113376-DE42-4B0E-BF0E-456AC8D44418%40ix.netcom.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/E18A42FF-CD44-40CD-84BA-2137F7CAE0CB%40ix.netcom.com.
