I'm struggling to understand, >From what I grasp this is a request for syntactic sugar to save typing: type intOptional *int and various new(intOptional) calls?
or is it purely about the interface to a json/xml/protobuf struct that may have optional fields present? If the second then surely it's a case of use protobuf/gob/the standard library? If it's the first then I guess it's a tradeoff between language complexity and laziness? Regards On Monday, 21 August 2017 14:39:30 UTC+1, Henrik Johansson wrote: > > I understand the the issue you are having. We had the same where we > differentiate between absent string and empty string. > It was messy with data from json but it worked. > > I think "int?", Optional or Maybe are not as helpful in Go as they can be > in Java or perhaps C# since a small type with custom marshalling can make > this safe when needed. > > That said, some standard way of denoting "absent" in cases with json or > protobuf (??) or xml would be nice. > How is this case catered to in for example gRPC? > > > > > mån 21 aug. 2017 kl 15:24 skrev Tong Sun <sunto...@gmail.com <javascript:> > >: > >> >> >> On Monday, August 21, 2017 at 3:44:41 AM UTC-4, Henry wrote: >> >> In my opinion, if you need a nullable type, you're entering a domain >>> problem. You are better off creating your own ADT (abstract data type) with >>> more descriptive names rather than "int?" or "float?". >> >> >> When we are talking about ADT, we are talking about extending the >> language itself. So I agree that it is a language problem, but do not agree >> it is a *domain only problem*, which is a polite way of saying, "that's >> your own problem, deal it yourself", because we've seen so many replies >> with so many suggestions and recommendations, i.e., just like what I >> suspected, you will see different people doing different things, which >> will be just like different people using different string implementation in >> C, and we end up with many C string libraries and implementations that are >> incompatible with each other. >> >> Again, whenever we are dealing with data, this (null situation) is >> inevitable. You are not suffering from the problem today do not mean that >> other people are not suffering, or you will never ever meet with it. >> I.e., in my view, it should be considered as part of the future Go. >> >> I do agree that there should be *more descriptive names rather than >> "int?" or "float?"*. That's why I only said "*like*" "int?", because >> there is no such name so far. >> >> -- >> 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...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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. For more options, visit https://groups.google.com/d/optout.
