Re: [go-nuts] Go 2 suggestion - Types like "int?"
I am not sure I follow your arguments here. ADTs are stuffs like Customer, Address, Invoice, etc. and I don't think they should be bolted into the language. They are abstract types you make your own so that you can describe your data in terms of the problem you are trying to solve. They are essentially your own responsibility to define. All I tried to say earlier is that since you needed more than a number (because you want to include null as one of the possible values), it seems to me you are better off defining your own data type. If you are doing JSON, you can define something like JSONNumber. It is more descriptive than "int?" and easier to maintain in the long run. On Monday, August 21, 2017 at 8:24:26 PM UTC+7, Tong Sun wrote: > > > 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
On Monday, August 21, 2017 at 10:27:11 AM UTC-4, Henrik Johansson wrote: I don't like needless boxing but I am not too keen on hiding it in the > type system either. > Without a standard way, you will sure see different people doing different things, and don't agree with each other. I'm not saying that such thing *should be* part of *Go language*, but I do consider "os", "time", "net/http" etc part of Go standard. -- 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.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
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 : > 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 : >> > >>> >>> 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.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
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 > >: > >> >> >> 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.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
On Mon, Aug 21, 2017 at 9:38 AM, 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? > In GRPC/protobuf, you use scalar values with syntax="proto2" (since that generates code that uses pointers, where nil means absent). For syntax="proto3", where absent and zero-value are intentionally indistinguishable, you would need to use a wrapper. Protobuf includes "well-known types" that wrap scalars. They are just boxes: a struct with a single scalar field (similar to Java's java.lang.Integer, for example) https://developers.google.com/protocol-buffers/docs/reference/google.protobuf (Int32Value, Int64Value, UInt32Value, UInt64Value, FloatValue, DoubleValue, BoolValue, and BytesValue) Fields of these types are represented as pointers to structs. If nil, the value is absent. If non-nil, the actual value is the single field of the target struct. > > > > > mån 21 aug. 2017 kl 15:24 skrev Tong Sun : > >> >> >> 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+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. > -- 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.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
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 : > > > 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+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.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
In general, I think that *T isn't a bad way to represent "maybe
there's a T here". The down sides of this representation are creation
(no easy to make a pointer to an int value inline without a helper
function), aliasing (if you copy the container, you haven't copied the
T value too) and cache unfriendliness (the T is likely to be stored
somewhere far away from its container).
One could imagine a Go with generics, in which it would be
straightforward to do something like:
type Maybe struct {
x T
valid bool
}
func (m Maybe) Get() (m.T, bool) {
return m.x, m.valid
}
func (m Maybe) MustGet() m.T {
if !m.valid {
panic("no value")
}
return m.x
}
func (m *Maybe) Set(x m.T) {
m.x, m.valid = x, true
}
func Just(x T) Maybe {
return Maybe{x, true}
}
In the meantime, to address the first down side at least, if I need to
create a few *int instances, I usually write a tiny helper function:
func newInt(i int) *int {
return &i
}
which at least makes creating them painless.
On 21 August 2017 at 08:44, 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?".
>
> --
> 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.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
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?". -- 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.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
I'd like to ask that everybody please stay polite on this thread. Thanks. I agree that as a language proposal this requires more description. To me the use case is not clear. I think I understand the basic idea, but I do not understand the specific problems that it solves. For example, it would help to see a problem statement, how it is written in Go today, and it would be written using this proposal. I also don't understand how to implement this. What is the representation of a value of type `T?` for all the different kinds of type `T` supported by Go. Ian -- 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.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
Thanks! In my view, whenever you are dealing with data, this (null situation) is inevitable, which makes it so useful and so fundamental that it should be considered as part of the future Go. Otherwise, you will see different people doing different things, 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. Go has done a great job eliminating such problems and should continue doing so. On Sun, Aug 20, 2017 at 1:13 PM, Tamás Gulácsi wrote: > Tgis is what sql.NullInt64 does, or github.com/guregu/null . > > -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/golang-nuts/EGwyXVCXrY8/unsubscribe. > To unsubscribe from this group and all its topics, 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.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
Tgis is what sql.NullInt64 does, or github.com/guregu/null . -- 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.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
On Sun, Aug 20, 2017 at 4:34 PM, Tong Sun wrote:
> > You seem to refuse to answer even the simplest questions about your
> proposal, like "what's the difference to using pointers?".
>
> The answer lies exactly in your reply -- see how inconvenient it is
> currently, just to deal with a single variable,
>
I don't believe it's inconvenient at all. It seems to be pretty much
exactly the same level as convenience as the C# example. It seems you are
placing a much larger value on this slightly different syntax than I (or
any other programmer I know).
whereas, what I'm dealing with is,
>
> Think of dealing with a json string of several meg, which full of nullable
> ints.
>
> Moreover,
>
> *In C#, just by adding a "?" to the end of the type solves the problem. *
>
The difference is, once again, as I put in my OP: *it is** causing
> tremendous problems for me so far, as I have to jump over the hoops to deal
> with them. *
> *In C#, just by adding a "?" to the end of the type solves the problem. *
>
I mentioned an example above, where the Go version of the code is
significantly shorter than the C# version and has the equivalent
complexity. It seems to me, that it serves as a good prototype of how Go
can - today - already do what you are asking but that you are stubbornly
keeping to your specific syntax without giving any justification or example
of how it would improve things.
> I.e. it's all above convenient. I've repeated myself several times now,
> and I don't care if you get it or not any more. That's why
>
> This is the end of the discussion
>
Okay, that is fair (I mean. It's not "fair", but I can accept it).
>
> On Sun, Aug 20, 2017 at 10:21 AM, Axel Wagner <
> axel.wagner...@googlemail.com> wrote:
>
>> On Sun, Aug 20, 2017 at 4:08 PM, Tong Sun wrote:
>>
>>> The
>>>
>>> fmt.Println(unmarshal(`{"foo": 3}`))
>>>
>>> prints a pointer instead of 3.
>>>
>>
>> Yes, it is a pointer to an integer holding the value 3. If you want it to
>> format differently, implement fmt.Stringer.
>>
>>
>>>
>>> This is NOT what I'm asking for, despite what you think.
>>>
>>
>> I am aware. The difference is - again - one of syntax, which I described
>> as "a very marginal benefit, at best".
>>
>>
>>> I think any further explanation is pointless, since you disagree from
>>> the very first. It'll be fruitless trying to make you look from other's
>>> view.
>>>
>>> All I'm trying to do is to make a point. So far it is *inconvenient*,
>>> to deal with the situation I've described. Think of dealing with a json
>>> string of several meg, which full of nullable ints. It is doable, but your
>>> "*int" is not the solution.
>>>
>>
>> How, specifically, is "int?" better? Again, describe the semantics of
>> what you are actually *suggesting*. From what I can tell, the two are
>> mechanically and bijectively translatable into each other. Looking at this
>> example: https://stackoverflow.com/questions/2690866/what-
>> is-the-purpose-of-a-question-mark-after-a-type-for-example-int-myvariabl
>>
>> You'd write that in go as
>>
>> var num *int
>>
>> // Is the HasValue property true?
>> if num != nil {
>> fmt.Println("num = " + *num)
>> } else {
>> fmt.Println("num = Nil");
>> }
>>
>> // y is set to zero
>> var y int
>> if num != nil {
>> y = *num
>> }
>>
>> // num.Value throws an InvalidOperationException if num.HasValue is false
>> defer func() {
>> if v := recover(); v != nil {
>> fmt.Println("panic:", v)
>> }
>> }()
>> y = *num
>>
>> Yes, there obviously is a difference. But it is a very minor one.
>>
>>
>>> This is the end of the discussion.
>>>
>>
>> What discussion? You seem to refuse to answer even the simplest questions
>> about your proposal, like "what's the difference to using pointers?".
>>
>>
>>> And I'm only asking for consideration in my OP.
>>>
>>
>>>
>>>
>>> On Sun, Aug 20, 2017 at 9:45 AM, Axel Wagner <
>>> axel.wagner...@googlemail.com> wrote:
>>>
On Sun, Aug 20, 2017 at 3:21 PM, Tong Sun wrote:
> On Sun, Aug 20, 2017 at 2:22 AM, Axel Wagner <
> axel.wagner...@googlemail.com> wrote:
>
> ii := new(int)
>> (*ii) = 3
>> (*ii)++
>>
>> Yes, it's not exactly the same syntax. It still demonstrates that
>> what you are suggesting creates, at best, very marginal benefit.
>>
>
> This is where I don't agree on.
>
> var ii *int
>>
>
> This is what you are suggesting, how to define the variable. I.e., *to
> replace "int?"*.
>
Again, what you write as "int?", you write as "*int" instead. What you
describe as "int?" is a type, that can either contain an int, or nothing.
That is exactly what pointers do; they are either nil, or contain a
reference to an int.
>
> ii = 3
>>
>
> This is what I believe what will happen if I parse json '{"ii", 3}'
> into it,
>
The semantics of particular packages is what they choose. In the case
of encoding/json, it
Re: [go-nuts] Go 2 suggestion - Types like "int?"
> You seem to refuse to answer even the simplest questions about your
proposal, like "what's the difference to using pointers?".
The answer lies exactly in your reply -- see how inconvenient it is
currently, just to deal with a single variable, whereas, what I'm dealing
with is,
Think of dealing with a json string of several meg, which full of nullable
ints.
Moreover,
*In C#, just by adding a "?" to the end of the type solves the problem. *
The difference is, once again, as I put in my OP: *it is** causing
tremendous problems for me so far, as I have to jump over the hoops to deal
with them. *
*In C#, just by adding a "?" to the end of the type solves the problem. *
I.e. it's all above convenient. I've repeated myself several times now, and
I don't care if you get it or not any more. That's why
This is the end of the discussion
On Sun, Aug 20, 2017 at 10:21 AM, Axel Wagner wrote:
> On Sun, Aug 20, 2017 at 4:08 PM, Tong Sun wrote:
>
>> The
>>
>> fmt.Println(unmarshal(`{"foo": 3}`))
>>
>> prints a pointer instead of 3.
>>
>
> Yes, it is a pointer to an integer holding the value 3. If you want it to
> format differently, implement fmt.Stringer.
>
>
>>
>> This is NOT what I'm asking for, despite what you think.
>>
>
> I am aware. The difference is - again - one of syntax, which I described
> as "a very marginal benefit, at best".
>
>
>> I think any further explanation is pointless, since you disagree from the
>> very first. It'll be fruitless trying to make you look from other's view.
>>
>> All I'm trying to do is to make a point. So far it is *inconvenient*, to
>> deal with the situation I've described. Think of dealing with a json string
>> of several meg, which full of nullable ints. It is doable, but your "*int"
>> is not the solution.
>>
>
> How, specifically, is "int?" better? Again, describe the semantics of what
> you are actually *suggesting*. From what I can tell, the two are
> mechanically and bijectively translatable into each other. Looking at this
> example: https://stackoverflow.com/questions/2690866/what-is-the-purpose-
> of-a-question-mark-after-a-type-for-example-int-myvariabl
>
> You'd write that in go as
>
> var num *int
>
> // Is the HasValue property true?
> if num != nil {
> fmt.Println("num = " + *num)
> } else {
> fmt.Println("num = Nil");
> }
>
> // y is set to zero
> var y int
> if num != nil {
> y = *num
> }
>
> // num.Value throws an InvalidOperationException if num.HasValue is false
> defer func() {
> if v := recover(); v != nil {
> fmt.Println("panic:", v)
> }
> }()
> y = *num
>
> Yes, there obviously is a difference. But it is a very minor one.
>
>
>> This is the end of the discussion.
>>
>
> What discussion? You seem to refuse to answer even the simplest questions
> about your proposal, like "what's the difference to using pointers?".
>
>
>> And I'm only asking for consideration in my OP.
>>
>
>>
>>
>> On Sun, Aug 20, 2017 at 9:45 AM, Axel Wagner <
>> axel.wagner...@googlemail.com> wrote:
>>
>>> On Sun, Aug 20, 2017 at 3:21 PM, Tong Sun wrote:
>>>
On Sun, Aug 20, 2017 at 2:22 AM, Axel Wagner <
axel.wagner...@googlemail.com> wrote:
ii := new(int)
> (*ii) = 3
> (*ii)++
>
> Yes, it's not exactly the same syntax. It still demonstrates that what
> you are suggesting creates, at best, very marginal benefit.
>
This is where I don't agree on.
var ii *int
>
This is what you are suggesting, how to define the variable. I.e., *to
replace "int?"*.
>>>
>>> Again, what you write as "int?", you write as "*int" instead. What you
>>> describe as "int?" is a type, that can either contain an int, or nothing.
>>> That is exactly what pointers do; they are either nil, or contain a
>>> reference to an int.
>>>
>>>
ii = 3
>
This is what I believe what will happen if I parse json '{"ii", 3}'
into it,
>>>
>>> The semantics of particular packages is what they choose. In the case of
>>> encoding/json, it does what you want: https://play.golang.org/
>>> p/3XIimrd6RF
>>>
>>> or read 3 from DB into it.
>>>
>>> I don't know how database/sql behaves in this matter. I suspect to a
>>> degree that depends on the driver. In any case, this is a library-problem,
>>> not a language problem.
>>>
>>>
If not, then you didn't do a good job explaining your point.
>>>
>>> You made a suggestion for a language change. I believe it is fair to put
>>> the onus of explanation on you here. Both of what the expected benefits of
>>> your proposal are and why the current semantics aren't enough.
>>>
>>> ii++
This demonstrate how I can deal with a "int?" variable in C#.
>>>
>>> And I demonstrated how you can deal with a "*int" variable in Go in
>>> exactly the same manner. I demonstrated that your suggestion seems to be
>>> exactly that: That you want to write "ii++" instead of writing "(*ii)++". I
>>> summarized that as "a very mar
Re: [go-nuts] Go 2 suggestion - Types like "int?"
On Sun, Aug 20, 2017 at 4:08 PM, Tong Sun wrote:
> The
>
> fmt.Println(unmarshal(`{"foo": 3}`))
>
> prints a pointer instead of 3.
>
Yes, it is a pointer to an integer holding the value 3. If you want it to
format differently, implement fmt.Stringer.
>
> This is NOT what I'm asking for, despite what you think.
>
I am aware. The difference is - again - one of syntax, which I described as
"a very marginal benefit, at best".
> I think any further explanation is pointless, since you disagree from the
> very first. It'll be fruitless trying to make you look from other's view.
>
> All I'm trying to do is to make a point. So far it is *inconvenient*, to
> deal with the situation I've described. Think of dealing with a json string
> of several meg, which full of nullable ints. It is doable, but your "*int"
> is not the solution.
>
How, specifically, is "int?" better? Again, describe the semantics of what
you are actually *suggesting*. From what I can tell, the two are
mechanically and bijectively translatable into each other. Looking at this
example:
https://stackoverflow.com/questions/2690866/what-is-the-purpose-of-a-question-mark-after-a-type-for-example-int-myvariabl
You'd write that in go as
var num *int
// Is the HasValue property true?
if num != nil {
fmt.Println("num = " + *num)
} else {
fmt.Println("num = Nil");
}
// y is set to zero
var y int
if num != nil {
y = *num
}
// num.Value throws an InvalidOperationException if num.HasValue is false
defer func() {
if v := recover(); v != nil {
fmt.Println("panic:", v)
}
}()
y = *num
Yes, there obviously is a difference. But it is a very minor one.
> This is the end of the discussion.
>
What discussion? You seem to refuse to answer even the simplest questions
about your proposal, like "what's the difference to using pointers?".
> And I'm only asking for consideration in my OP.
>
>
>
> On Sun, Aug 20, 2017 at 9:45 AM, Axel Wagner <
> axel.wagner...@googlemail.com> wrote:
>
>> On Sun, Aug 20, 2017 at 3:21 PM, Tong Sun wrote:
>>
>>> On Sun, Aug 20, 2017 at 2:22 AM, Axel Wagner <
>>> axel.wagner...@googlemail.com> wrote:
>>>
>>> ii := new(int)
(*ii) = 3
(*ii)++
Yes, it's not exactly the same syntax. It still demonstrates that what
you are suggesting creates, at best, very marginal benefit.
>>>
>>> This is where I don't agree on.
>>>
>>> var ii *int
>>>
>>> This is what you are suggesting, how to define the variable. I.e., *to
>>> replace "int?"*.
>>>
>>
>> Again, what you write as "int?", you write as "*int" instead. What you
>> describe as "int?" is a type, that can either contain an int, or nothing.
>> That is exactly what pointers do; they are either nil, or contain a
>> reference to an int.
>>
>>
>>>
>>> ii = 3
>>>
>>> This is what I believe what will happen if I parse json '{"ii", 3}' into
>>> it,
>>>
>>
>> The semantics of particular packages is what they choose. In the case of
>> encoding/json, it does what you want: https://play.golang.org/
>> p/3XIimrd6RF
>>
>> or read 3 from DB into it.
>>>
>>
>> I don't know how database/sql behaves in this matter. I suspect to a
>> degree that depends on the driver. In any case, this is a library-problem,
>> not a language problem.
>>
>>
>>> If not, then you didn't do a good job explaining your point.
>>>
>>
>> You made a suggestion for a language change. I believe it is fair to put
>> the onus of explanation on you here. Both of what the expected benefits of
>> your proposal are and why the current semantics aren't enough.
>>
>> ii++
>>>
>>>
>>> This demonstrate how I can deal with a "int?" variable in C#.
>>>
>>
>> And I demonstrated how you can deal with a "*int" variable in Go in
>> exactly the same manner. I demonstrated that your suggestion seems to be
>> exactly that: That you want to write "ii++" instead of writing "(*ii)++". I
>> summarized that as "a very marginal benefit at best".
>>
>>
>>> So, all in all, you are either shooting without fully understand what I
>>> am asking, or don't understand what "int?" actually means in C#, or both.
>>>
>>
>> Then explain better what you are asking for. I indeed don't know C#. But
>> I understand the ?-operator to be the equivalent of Maybe in Haskell or
>> Option in rust, the semantics of both I described above. Pointers are
>> providing the corresponding semantics for Go.
>>
>>
>>>
>>>
On Sun, Aug 20, 2017 at 8:00 AM, Tong Sun wrote:
> I did. why there are always people assuming the other party
> they are talking to is just silly.
>
> Anyway, this is what i got:
>
> var ii *int
> ii = 3
> ii++
>
> cannot use 3 (type int) as type *int in assignment
>
> invalid operation: ii++ (non-numeric type *int)
>
>
>
> On Sun, Aug 20, 2017 at 1:24 AM, Tyler Compton
> wrote:
>
>> I don't think it's immediately obvious what use cases this "int?"
>> proposal delivers that aren't covered by "*int". The e
Re: [go-nuts] Go 2 suggestion - Types like "int?"
On Sun, Aug 20, 2017 at 10:06 AM, Wojciech S. Czarnecki wrote: Ah, so Go core team should puff, bow then break Go type system asap. > Just because some sloppy coder in outer world may produce invalid data > and present coder is too lazy to write proper validation for that? > This is in correct. Did I ask for breaking Go type system asap? No. I asked for *consideration* for *next gen* Go. Are there lazy coder fails to write proper validation? Maybe, but it is not the point. Is every single int or float type has to be not null in DB? No. So your perception is off, it is not because of sloppy or lazy coder -- There is a demands out there. And, BTW, thanks for your detailed explanations elsewhere, ;) -- 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.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
The
fmt.Println(unmarshal(`{"foo": 3}`))
prints a pointer instead of 3.
This is NOT what I'm asking for, despite what you think. I think any
further explanation is pointless, since you disagree from the very first.
It'll be fruitless trying to make you look from other's view.
All I'm trying to do is to make a point. So far it is *inconvenient*, to
deal with the situation I've described. Think of dealing with a json string
of several meg, which full of nullable ints. It is doable, but your "*int"
is not the solution.
This is the end of the discussion.
And I'm only asking for consideration in my OP.
On Sun, Aug 20, 2017 at 9:45 AM, Axel Wagner
wrote:
> On Sun, Aug 20, 2017 at 3:21 PM, Tong Sun wrote:
>
>> On Sun, Aug 20, 2017 at 2:22 AM, Axel Wagner <
>> axel.wagner...@googlemail.com> wrote:
>>
>> ii := new(int)
>>> (*ii) = 3
>>> (*ii)++
>>>
>>> Yes, it's not exactly the same syntax. It still demonstrates that what
>>> you are suggesting creates, at best, very marginal benefit.
>>>
>>
>> This is where I don't agree on.
>>
>> var ii *int
>>>
>>
>> This is what you are suggesting, how to define the variable. I.e., *to
>> replace "int?"*.
>>
>
> Again, what you write as "int?", you write as "*int" instead. What you
> describe as "int?" is a type, that can either contain an int, or nothing.
> That is exactly what pointers do; they are either nil, or contain a
> reference to an int.
>
>
>>
>> ii = 3
>>>
>>
>> This is what I believe what will happen if I parse json '{"ii", 3}' into
>> it,
>>
>
> The semantics of particular packages is what they choose. In the case of
> encoding/json, it does what you want: https://play.golang.org/p/3XIimrd6RF
>
> or read 3 from DB into it.
>>
>
> I don't know how database/sql behaves in this matter. I suspect to a
> degree that depends on the driver. In any case, this is a library-problem,
> not a language problem.
>
>
>> If not, then you didn't do a good job explaining your point.
>>
>
> You made a suggestion for a language change. I believe it is fair to put
> the onus of explanation on you here. Both of what the expected benefits of
> your proposal are and why the current semantics aren't enough.
>
> ii++
>>
>>
>> This demonstrate how I can deal with a "int?" variable in C#.
>>
>
> And I demonstrated how you can deal with a "*int" variable in Go in
> exactly the same manner. I demonstrated that your suggestion seems to be
> exactly that: That you want to write "ii++" instead of writing "(*ii)++". I
> summarized that as "a very marginal benefit at best".
>
>
>> So, all in all, you are either shooting without fully understand what I
>> am asking, or don't understand what "int?" actually means in C#, or both.
>>
>
> Then explain better what you are asking for. I indeed don't know C#. But I
> understand the ?-operator to be the equivalent of Maybe in Haskell or
> Option in rust, the semantics of both I described above. Pointers are
> providing the corresponding semantics for Go.
>
>
>>
>>
>>> On Sun, Aug 20, 2017 at 8:00 AM, Tong Sun wrote:
>>>
I did. why there are always people assuming the other party they
are talking to is just silly.
Anyway, this is what i got:
var ii *int
ii = 3
ii++
cannot use 3 (type int) as type *int in assignment
invalid operation: ii++ (non-numeric type *int)
On Sun, Aug 20, 2017 at 1:24 AM, Tyler Compton
wrote:
> I don't think it's immediately obvious what use cases this "int?"
> proposal delivers that aren't covered by "*int". The encoding/json package
> uses pointers to support null JSON values.
>
> As a more general point, when someone answers your question, they're
> taking time out of their day to help you. I think it's reasonable for the
> burden of proof to be put upon the asker, who is looking to others for
> help.
>
> On Sat, Aug 19, 2017 at 9:28 PM Tong Sun wrote:
>
>> Oh yeah? Are you sure what you are answering is what I'm asking?
>>
>> Please try to understand what people are asking before showing off
>> yourself, or post concrete example to proof that you understand correctly
>> what people are asking.
>>
>> On Sat, Aug 19, 2017 at 4:02 PM, Axel Wagner <
>> axel.wagner...@googlemail.com> wrote:
>>
>>> Go can do what you want today, just that it's spelled "*int".
>>>
>>> On Sat, Aug 19, 2017 at 6:01 PM, Tong Sun
>>> wrote:
>>>
- "int?" will be a different type than "int". I.e., we know very
well what we are sacrificing when we choose that type.
- There is a demand there, json and/or sql. Denying it won't make
it go away.
(*Sorry to Jan, was sending to the wrong place*)
On Sat, Aug 19, 2017 at 11:54 AM, Jan Mercl <0xj...@gmail.com>
wrote:
> On Sat, Aug 19, 2017 at 5:05 PM Tong Sun
> wrote:
>
> > Suggesting C# type syn
Re: [go-nuts] Go 2 suggestion - Types like "int?"
On Sat, 19 Aug 2017 08:05:34 -0700 (PDT)
Tong Sun wrote:
> Suggesting C# type syntax like "int*?*" so as to take nil as valid value.
Should 'int' type also support a 'NaN' then?
Nil (NULL) is *not* a number. Thats why it has its own keyword, one almost
universally associated with pointers only. Implicit cast from apples
to oranges many other languages allow is a plain evil and go compiler says
you so.
In Go int is for numbers, not for pointers. Metal stuck type (machine word)
for storing pointers as numbers is called uintptr. What you called for has a
'Maybe' name. I would like Go2 to switch entirely from nils to Maybes,
but have not too much hope it will.
> In C#, just by adding a "?" to the end of the type solves the problem.
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/nullable-types/
'T?' is a syntax sugar for Nullable. It instantiates a struct you can also
write in in Go:
type Mint struct { // Maybe (or Optional) int.
value int
validNum bool // NaN/nil at birth
}
func (t *Mint) IsNil() bool {
return !t.validNum
}
One may also generalize it:
type Nillable interface { // Maybes
IsNil () bool
}
Now one who uses above Nillable does know its cost
and will not confuse some laguage's syntax sugar for standard
library compound types (and calls) with language's builtin.
> However, more and more people are using json to transport data, and there
> will be times that json may be invalid. I.e., the "int" type has 'null' as
> input.
Ah, so Go core team should puff, bow then break Go type system asap.
Just because some sloppy coder in outer world may produce invalid data
and present coder is too lazy to write proper validation for that?
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
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.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
On Sun, Aug 20, 2017 at 3:21 PM, Tong Sun wrote:
> On Sun, Aug 20, 2017 at 2:22 AM, Axel Wagner <
> axel.wagner...@googlemail.com> wrote:
>
> ii := new(int)
>> (*ii) = 3
>> (*ii)++
>>
>> Yes, it's not exactly the same syntax. It still demonstrates that what
>> you are suggesting creates, at best, very marginal benefit.
>>
>
> This is where I don't agree on.
>
> var ii *int
>>
>
> This is what you are suggesting, how to define the variable. I.e., *to
> replace "int?"*.
>
Again, what you write as "int?", you write as "*int" instead. What you
describe as "int?" is a type, that can either contain an int, or nothing.
That is exactly what pointers do; they are either nil, or contain a
reference to an int.
>
> ii = 3
>>
>
> This is what I believe what will happen if I parse json '{"ii", 3}' into
> it,
>
The semantics of particular packages is what they choose. In the case of
encoding/json, it does what you want: https://play.golang.org/p/3XIimrd6RF
or read 3 from DB into it.
>
I don't know how database/sql behaves in this matter. I suspect to a degree
that depends on the driver. In any case, this is a library-problem, not a
language problem.
> If not, then you didn't do a good job explaining your point.
>
You made a suggestion for a language change. I believe it is fair to put
the onus of explanation on you here. Both of what the expected benefits of
your proposal are and why the current semantics aren't enough.
ii++
>
>
> This demonstrate how I can deal with a "int?" variable in C#.
>
And I demonstrated how you can deal with a "*int" variable in Go in exactly
the same manner. I demonstrated that your suggestion seems to be exactly
that: That you want to write "ii++" instead of writing "(*ii)++". I
summarized that as "a very marginal benefit at best".
> So, all in all, you are either shooting without fully understand what I am
> asking, or don't understand what "int?" actually means in C#, or both.
>
Then explain better what you are asking for. I indeed don't know C#. But I
understand the ?-operator to be the equivalent of Maybe in Haskell or
Option in rust, the semantics of both I described above. Pointers are
providing the corresponding semantics for Go.
>
>
>> On Sun, Aug 20, 2017 at 8:00 AM, Tong Sun wrote:
>>
>>> I did. why there are always people assuming the other party they
>>> are talking to is just silly.
>>>
>>> Anyway, this is what i got:
>>>
>>> var ii *int
>>> ii = 3
>>> ii++
>>>
>>> cannot use 3 (type int) as type *int in assignment
>>>
>>> invalid operation: ii++ (non-numeric type *int)
>>>
>>>
>>>
>>> On Sun, Aug 20, 2017 at 1:24 AM, Tyler Compton
>>> wrote:
>>>
I don't think it's immediately obvious what use cases this "int?"
proposal delivers that aren't covered by "*int". The encoding/json package
uses pointers to support null JSON values.
As a more general point, when someone answers your question, they're
taking time out of their day to help you. I think it's reasonable for the
burden of proof to be put upon the asker, who is looking to others for
help.
On Sat, Aug 19, 2017 at 9:28 PM Tong Sun wrote:
> Oh yeah? Are you sure what you are answering is what I'm asking?
>
> Please try to understand what people are asking before showing off
> yourself, or post concrete example to proof that you understand correctly
> what people are asking.
>
> On Sat, Aug 19, 2017 at 4:02 PM, Axel Wagner <
> axel.wagner...@googlemail.com> wrote:
>
>> Go can do what you want today, just that it's spelled "*int".
>>
>> On Sat, Aug 19, 2017 at 6:01 PM, Tong Sun
>> wrote:
>>
>>> - "int?" will be a different type than "int". I.e., we know very
>>> well what we are sacrificing when we choose that type.
>>> - There is a demand there, json and/or sql. Denying it won't make it
>>> go away.
>>>
>>> (*Sorry to Jan, was sending to the wrong place*)
>>>
>>> On Sat, Aug 19, 2017 at 11:54 AM, Jan Mercl <0xj...@gmail.com>
>>> wrote:
>>>
On Sat, Aug 19, 2017 at 5:05 PM Tong Sun
wrote:
> Suggesting C# type syntax like "int?" so as to take nil as valid
value.
- As int is not a pointer type, what would nil int mean?
- Are you willing to sacrifice extra storage for the additional
isNil information or do you prefer that int cannot represent
2^(sizeof(int)*8) different values?
- (xyproblem?) If you need the information like 'isValid', why a
separate bool [field] is not enough?
--
-j
>>>
>>> --
>>> 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://group
Re: [go-nuts] Go 2 suggestion - Types like "int?"
On Sun, Aug 20, 2017 at 2:22 AM, Axel Wagner
wrote:
ii := new(int)
> (*ii) = 3
> (*ii)++
>
> Yes, it's not exactly the same syntax. It still demonstrates that what you
> are suggesting creates, at best, very marginal benefit.
>
This is where I don't agree on.
var ii *int
>
This is what you are suggesting, how to define the variable. I.e., *to
replace "int?"*.
ii = 3
>
This is what I believe what will happen if I parse json '{"ii", 3}' into
it, or read 3 from DB into it. If not, then you didn't do a good job
explaining your point.
> ii++
This demonstrate how I can deal with a "int?" variable in C#.
So, all in all, you are either shooting without fully understand what I am
asking, or don't understand what "int?" actually means in C#, or both.
> On Sun, Aug 20, 2017 at 8:00 AM, Tong Sun wrote:
>
>> I did. why there are always people assuming the other party they
>> are talking to is just silly.
>>
>> Anyway, this is what i got:
>>
>> var ii *int
>> ii = 3
>> ii++
>>
>> cannot use 3 (type int) as type *int in assignment
>>
>> invalid operation: ii++ (non-numeric type *int)
>>
>>
>>
>> On Sun, Aug 20, 2017 at 1:24 AM, Tyler Compton wrote:
>>
>>> I don't think it's immediately obvious what use cases this "int?"
>>> proposal delivers that aren't covered by "*int". The encoding/json package
>>> uses pointers to support null JSON values.
>>>
>>> As a more general point, when someone answers your question, they're
>>> taking time out of their day to help you. I think it's reasonable for the
>>> burden of proof to be put upon the asker, who is looking to others for help.
>>>
>>> On Sat, Aug 19, 2017 at 9:28 PM Tong Sun wrote:
>>>
Oh yeah? Are you sure what you are answering is what I'm asking?
Please try to understand what people are asking before showing off
yourself, or post concrete example to proof that you understand correctly
what people are asking.
On Sat, Aug 19, 2017 at 4:02 PM, Axel Wagner <
axel.wagner...@googlemail.com> wrote:
> Go can do what you want today, just that it's spelled "*int".
>
> On Sat, Aug 19, 2017 at 6:01 PM, Tong Sun
> wrote:
>
>> - "int?" will be a different type than "int". I.e., we know very well
>> what we are sacrificing when we choose that type.
>> - There is a demand there, json and/or sql. Denying it won't make it
>> go away.
>>
>> (*Sorry to Jan, was sending to the wrong place*)
>>
>> On Sat, Aug 19, 2017 at 11:54 AM, Jan Mercl <0xj...@gmail.com> wrote:
>>
>>> On Sat, Aug 19, 2017 at 5:05 PM Tong Sun
>>> wrote:
>>>
>>> > Suggesting C# type syntax like "int?" so as to take nil as valid
>>> value.
>>>
>>> - As int is not a pointer type, what would nil int mean?
>>>
>>> - Are you willing to sacrifice extra storage for the additional
>>> isNil information or do you prefer that int cannot represent
>>> 2^(sizeof(int)*8) different values?
>>>
>>> - (xyproblem?) If you need the information like 'isValid', why a
>>> separate bool [field] is not enough?
>>>
>>> --
>>>
>>> -j
>>>
>>
>> --
>> 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.
>>>
>>
>
--
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.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
ii := new(int) (*ii) = 3 (*ii)++ Yes, it's not exactly the same syntax. It still demonstrates that what you are suggesting creates, at best, very marginal benefit. On Sun, Aug 20, 2017 at 8:00 AM, Tong Sun wrote: > I did. why there are always people assuming the other party they > are talking to is just silly. > > Anyway, this is what i got: > > var ii *int > ii = 3 > ii++ > > cannot use 3 (type int) as type *int in assignment > > invalid operation: ii++ (non-numeric type *int) > > > > On Sun, Aug 20, 2017 at 1:24 AM, Tyler Compton wrote: > >> I don't think it's immediately obvious what use cases this "int?" >> proposal delivers that aren't covered by "*int". The encoding/json package >> uses pointers to support null JSON values. >> >> As a more general point, when someone answers your question, they're >> taking time out of their day to help you. I think it's reasonable for the >> burden of proof to be put upon the asker, who is looking to others for help. >> >> On Sat, Aug 19, 2017 at 9:28 PM Tong Sun wrote: >> >>> Oh yeah? Are you sure what you are answering is what I'm asking? >>> >>> Please try to understand what people are asking before showing off >>> yourself, or post concrete example to proof that you understand correctly >>> what people are asking. >>> >>> On Sat, Aug 19, 2017 at 4:02 PM, Axel Wagner < >>> axel.wagner...@googlemail.com> wrote: >>> Go can do what you want today, just that it's spelled "*int". On Sat, Aug 19, 2017 at 6:01 PM, Tong Sun wrote: > - "int?" will be a different type than "int". I.e., we know very well > what we are sacrificing when we choose that type. > - There is a demand there, json and/or sql. Denying it won't make it > go away. > > (*Sorry to Jan, was sending to the wrong place*) > > On Sat, Aug 19, 2017 at 11:54 AM, Jan Mercl <0xj...@gmail.com> wrote: > >> On Sat, Aug 19, 2017 at 5:05 PM Tong Sun >> wrote: >> >> > Suggesting C# type syntax like "int?" so as to take nil as valid >> value. >> >> - As int is not a pointer type, what would nil int mean? >> >> - Are you willing to sacrifice extra storage for the additional isNil >> information or do you prefer that int cannot represent 2^(sizeof(int)*8) >> different values? >> >> - (xyproblem?) If you need the information like 'isValid', why a >> separate bool [field] is not enough? >> >> -- >> >> -j >> > > -- > 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. >>> >> > -- 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.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
I did. why there are always people assuming the other party they are talking to is just silly. Anyway, this is what i got: var ii *int ii = 3 ii++ cannot use 3 (type int) as type *int in assignment invalid operation: ii++ (non-numeric type *int) On Sun, Aug 20, 2017 at 1:24 AM, Tyler Compton wrote: > I don't think it's immediately obvious what use cases this "int?" proposal > delivers that aren't covered by "*int". The encoding/json package uses > pointers to support null JSON values. > > As a more general point, when someone answers your question, they're > taking time out of their day to help you. I think it's reasonable for the > burden of proof to be put upon the asker, who is looking to others for help. > > On Sat, Aug 19, 2017 at 9:28 PM Tong Sun wrote: > >> Oh yeah? Are you sure what you are answering is what I'm asking? >> >> Please try to understand what people are asking before showing off >> yourself, or post concrete example to proof that you understand correctly >> what people are asking. >> >> On Sat, Aug 19, 2017 at 4:02 PM, Axel Wagner < >> axel.wagner...@googlemail.com> wrote: >> >>> Go can do what you want today, just that it's spelled "*int". >>> >>> On Sat, Aug 19, 2017 at 6:01 PM, Tong Sun wrote: >>> - "int?" will be a different type than "int". I.e., we know very well what we are sacrificing when we choose that type. - There is a demand there, json and/or sql. Denying it won't make it go away. (*Sorry to Jan, was sending to the wrong place*) On Sat, Aug 19, 2017 at 11:54 AM, Jan Mercl <0xj...@gmail.com> wrote: > On Sat, Aug 19, 2017 at 5:05 PM Tong Sun wrote: > > > Suggesting C# type syntax like "int?" so as to take nil as valid > value. > > - As int is not a pointer type, what would nil int mean? > > - Are you willing to sacrifice extra storage for the additional isNil > information or do you prefer that int cannot represent 2^(sizeof(int)*8) > different values? > > - (xyproblem?) If you need the information like 'isValid', why a > separate bool [field] is not enough? > > -- > > -j > -- 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. >> > -- 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.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
I don't think it's immediately obvious what use cases this "int?" proposal delivers that aren't covered by "*int". The encoding/json package uses pointers to support null JSON values. As a more general point, when someone answers your question, they're taking time out of their day to help you. I think it's reasonable for the burden of proof to be put upon the asker, who is looking to others for help. On Sat, Aug 19, 2017 at 9:28 PM Tong Sun wrote: > Oh yeah? Are you sure what you are answering is what I'm asking? > > Please try to understand what people are asking before showing off > yourself, or post concrete example to proof that you understand correctly > what people are asking. > > On Sat, Aug 19, 2017 at 4:02 PM, Axel Wagner < > axel.wagner...@googlemail.com> wrote: > >> Go can do what you want today, just that it's spelled "*int". >> >> On Sat, Aug 19, 2017 at 6:01 PM, Tong Sun wrote: >> >>> - "int?" will be a different type than "int". I.e., we know very well >>> what we are sacrificing when we choose that type. >>> - There is a demand there, json and/or sql. Denying it won't make it go >>> away. >>> >>> (*Sorry to Jan, was sending to the wrong place*) >>> >>> On Sat, Aug 19, 2017 at 11:54 AM, Jan Mercl <0xj...@gmail.com> wrote: >>> On Sat, Aug 19, 2017 at 5:05 PM Tong Sun wrote: > Suggesting C# type syntax like "int?" so as to take nil as valid value. - As int is not a pointer type, what would nil int mean? - Are you willing to sacrifice extra storage for the additional isNil information or do you prefer that int cannot represent 2^(sizeof(int)*8) different values? - (xyproblem?) If you need the information like 'isValid', why a separate bool [field] is not enough? -- -j >>> >>> -- >>> 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. > -- 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.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
Oh yeah? Are you sure what you are answering is what I'm asking? Please try to understand what people are asking before showing off yourself, or post concrete example to proof that you understand correctly what people are asking. On Sat, Aug 19, 2017 at 4:02 PM, Axel Wagner wrote: > Go can do what you want today, just that it's spelled "*int". > > On Sat, Aug 19, 2017 at 6:01 PM, Tong Sun wrote: > >> - "int?" will be a different type than "int". I.e., we know very well >> what we are sacrificing when we choose that type. >> - There is a demand there, json and/or sql. Denying it won't make it go >> away. >> >> (*Sorry to Jan, was sending to the wrong place*) >> >> On Sat, Aug 19, 2017 at 11:54 AM, Jan Mercl <0xj...@gmail.com> wrote: >> >>> On Sat, Aug 19, 2017 at 5:05 PM Tong Sun wrote: >>> >>> > Suggesting C# type syntax like "int?" so as to take nil as valid >>> value. >>> >>> - As int is not a pointer type, what would nil int mean? >>> >>> - Are you willing to sacrifice extra storage for the additional isNil >>> information or do you prefer that int cannot represent 2^(sizeof(int)*8) >>> different values? >>> >>> - (xyproblem?) If you need the information like 'isValid', why a >>> separate bool [field] is not enough? >>> >>> -- >>> >>> -j >>> >> >> -- >> 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.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
Go can do what you want today, just that it's spelled "*int". On Sat, Aug 19, 2017 at 6:01 PM, Tong Sun wrote: > - "int?" will be a different type than "int". I.e., we know very well what > we are sacrificing when we choose that type. > - There is a demand there, json and/or sql. Denying it won't make it go > away. > > (*Sorry to Jan, was sending to the wrong place*) > > On Sat, Aug 19, 2017 at 11:54 AM, Jan Mercl <0xj...@gmail.com> wrote: > >> On Sat, Aug 19, 2017 at 5:05 PM Tong Sun wrote: >> >> > Suggesting C# type syntax like "int?" so as to take nil as valid value. >> >> - As int is not a pointer type, what would nil int mean? >> >> - Are you willing to sacrifice extra storage for the additional isNil >> information or do you prefer that int cannot represent 2^(sizeof(int)*8) >> different values? >> >> - (xyproblem?) If you need the information like 'isValid', why a separate >> bool [field] is not enough? >> >> -- >> >> -j >> > > -- > 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.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
- "int?" will be a different type than "int". I.e., we know very well what we are sacrificing when we choose that type. - There is a demand there, json and/or sql. Denying it won't make it go away. (*Sorry to Jan, was sending to the wrong place*) On Sat, Aug 19, 2017 at 11:54 AM, Jan Mercl <0xj...@gmail.com> wrote: > On Sat, Aug 19, 2017 at 5:05 PM Tong Sun wrote: > > > Suggesting C# type syntax like "int?" so as to take nil as valid value. > > - As int is not a pointer type, what would nil int mean? > > - Are you willing to sacrifice extra storage for the additional isNil > information or do you prefer that int cannot represent 2^(sizeof(int)*8) > different values? > > - (xyproblem?) If you need the information like 'isValid', why a separate > bool [field] is not enough? > > -- > > -j > -- 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.
Re: [go-nuts] Go 2 suggestion - Types like "int?"
On Sat, Aug 19, 2017 at 5:05 PM Tong Sun wrote: > Suggesting C# type syntax like "int?" so as to take nil as valid value. - As int is not a pointer type, what would nil int mean? - Are you willing to sacrifice extra storage for the additional isNil information or do you prefer that int cannot represent 2^(sizeof(int)*8) different values? - (xyproblem?) If you need the information like 'isValid', why a separate bool [field] is not enough? -- -j -- 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.
[go-nuts] Go 2 suggestion - Types like "int?"
sql.NullInt64 or alike with custom MarshalJSON and UnmarshalJSON? -- 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.
[go-nuts] Go 2 suggestion - Types like "int?"
Suggesting C# type syntax like "int*?*" so as to take nil as valid value. Currently: var i int i = nil will give: cannot use nil as type int in assignment However, more and more people are using json to transport data, and there will be times that json may be invalid. I.e., the "int" type has 'null' as input. This is causing tremendous problems for me so far, as I have to jump over the hoops to deal with them. In C#, just by adding a "?" to the end of the type solves the problem. Please consider. -- 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.
