I guess anywhere where absent and the default value introduces some ambiguity. But as Josh so nicely describes the gRPC case the solution is boxing.
I don't mind I think. I don't like needless boxing but I am not too keen on hiding it in the type system either. mån 21 aug. 2017 kl 15:51 skrev Chris Hopkins <cbehopk...@gmail.com>: > 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>: >> > >>> >>> 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. >> >> >>> 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. > -- 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.
