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 ess
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 no
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 Ch
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'
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 a
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 m
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 A
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 unfr
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" gro
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
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 differen
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 op
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 var
> 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
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, despit
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.
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
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
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,
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
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
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 Compt
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 t
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 w
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'
- "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..
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 r
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 mo
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 ha
29 matches
Mail list logo
