"""
But once you start saying that we are going to reject
storing nil in an interface value unless it is weak, then you are
greatly complicating the type system.
"""
With regards to controls on nil this is a static analysis tool, not
something I expect to be forced on anyone.
As I understand it all interface types carry their concrete type with them,
and this would only complain about the assignment of (nil, nil), it would
not effect the zero value.
Users of the official golang compiler would never even need to be told this
is a thing. the golang compiler only needs to quietly throw away the weak
keyword when it is found in type declaration such that any code written to
an experimental fork could be safely built with the official compiler.
On Mon, Feb 13, 2017 at 5:04 PM, Ian Lance Taylor <i...@golang.org> wrote:
> On Fri, Feb 10, 2017 at 10:04 PM, Keynan Pratt <kpr...@atlassian.com>
> wrote:
> > Yes it CAN be implemented that way, but that throws away type
> information,
> > and makes code less readable.
>
> The question of compile-time type information boils down to the generics
> issue.
>
> > It also seems to conflate the difference
> > between language and library, i suppose go has already trod that bridge.
> > What I'm asking for is something that can be used to reason about
> programs
> > at compile time. It seems like an opaque type at runtime wouldn't achieve
> > this. For example, if you where to implement this type could I still do
> >
> > var x interface{} = nil
> >
> > ?
> >
> > If you have weak as a language feature you can make that illegal,
> insisting
> > that only
> >
> > var x weak interface{} = nil
> >
> > is allowed, and any program written for a compiler that enforces
> > non-nullable strong pointers would be valid to compile with the official
> > compiler. Fast compile time is great, it's part of the reason I love go.
> But
> > it would be nice to have a flag I can turn on that gets me some of those
> > wonderful correctness checking features that you see in languages with
> > stronger type systems. Avoiding nulls just seems like the bare minimum.
> So
> > those are the things we theoretically get. On the other hand what is the
> > cost of adding this? I suspect it is (very) small and I also acknowledge
> it
> > will never get added. I just think that's a shame.
>
> I'm sorry, but that doesn't seem to me like Go. Go is a language with
> a simple type system. I can understand how weak pointers could fit
> into Go. But once you start saying that we are going to reject
> storing nil in an interface value unless it is weak, then you are
> greatly complicating the type system. The cost of adding that kind of
> complexity to the language is high. The cost is not in
> implementation--though I don't see offhand how to implement it, since
> now non-weak interfaces have no zero value--the cost is in requiring
> everybody learning the language to learn a complex new concept.
>
> 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.
