You can already achieve all of this without any kind of language change or
cooperation from the go-team. Just add an annotation in a comment (e.g.
"//foo:weak") on declarations of "weak" pointers and then have the tool
look for them and do its analysis.
On Mon, Feb 13, 2017 at 12:18 PM, Keynan Pratt <kpr...@atlassian.com> wrote:
> """
> 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.
>
--
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.
