Yes it CAN be implemented that way, but that throws away type information,
and makes code less readable. 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.
On Thu, Feb 9, 2017 at 11:04 PM, Keynan Pratt <kpr...@atlassian.com> wrote:
> In this scenario how does the runtime distinguish between a weak and
strong
> pointer? how does a developer ensure they are dealing with a weak or
strong
> pointer when declaring a struct?
In general, please reply to the mailing list, not just to me. Thanks.
A weak pointer has the opaque type runtime.WeakPointer. It has methods
Set(interface{})
Get() interface{}
The runtime can tell a weak pointer because it is the value stored in
a runtime.WeakPointer. The developer can ensure they are dealing with
a weak pointer by writing runtime.WeakPointer rather than *T.
On Sat, Feb 11, 2017 at 1:32 AM, Ian Lance Taylor <i...@golang.org> wrote:
> On Thu, Feb 9, 2017 at 11:04 PM, Keynan Pratt <kpr...@atlassian.com>
> wrote:
> > In this scenario how does the runtime distinguish between a weak and
> strong
> > pointer? how does a developer ensure they are dealing with a weak or
> strong
> > pointer when declaring a struct?
>
> In general, please reply to the mailing list, not just to me. Thanks.
>
> A weak pointer has the opaque type runtime.WeakPointer. It has methods
> Set(interface{})
> Get() interface{}
> The runtime can tell a weak pointer because it is the value stored in
> a runtime.WeakPointer. The developer can ensure they are dealing with
> a weak pointer by writing runtime.WeakPointer rather than *T.
>
> Ian
>
>
> > On Fri, Feb 10, 2017 at 3:55 PM, Ian Lance Taylor <i...@golang.org>
> wrote:
> >>
> >> On Thu, Feb 9, 2017 at 4:46 PM, <kpr...@atlassian.com> wrote:
> >> >
> >> > I'll look into that api and maybe it will solve my problems. Though,
> to
> >> > be
> >> > understood I'm not asking for ARC, I'm asking for a keyword so the
> spec
> >> > is
> >> > compatible with ARC.
> >>
> >> But you don't need a keyword to get weak pointers. Given the
> >> existence of concurrent GC, the only safe way to use a weak pointer
> >> for anything whatsoever is to call a runtime function that examines
> >> the weak pointer and returns nil if the object is gone or a strong
> >> pointer to the object if it is not. That strong pointer will then
> >> keep the object alive until you discard it. Since you have to call a
> >> runtime function anyhow, putting weak pointers into the language
> >> itself is not necessary. They can be implemented as an opaque type in
> >> the runtime package.
> >>
> >> 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.
