FAQ
Not sure if this is a bug or a feature, so I am posting here...

Preamble:

Go does not support const/immutable pointers.
Not a problem, because...

When I need to return a pointer reference to a chunk of data while
enforcing read-only access:

- I place my data in an unexported struct type with exported getters.
- I return a simple struct wrapper with an embedded pointer field.

..and there is virtually no speed penalty thanks to recent inlining
improvements in the compiler!!!

e.g.

type item {
     a int
}

func (this *item) A() int {
    return this.a
}

type readOnlyItem {
     *item
}

func myfunc() GetItem() readOnlyItem {
     return readOnlyItem {&myitem}
}

This works great in practice.

However, if I replace readOnlyItem above with an anonymous struct.
I get the following oddities:

- My package compiles ok.
- Importers of my package fail to compile with the following errors at the
import line.

unknown struct {} field 'mypackage.item' in struct literal
tempname called with nil type

Anonymous structs are so much cleaner in these situations and I cannot see
why they shouldn't work.
I have seen bug reports on the above errors, but they are not quite
identical to the above scenario.

If this is specified behaviour, should my package not fail to compile?
Or is this indeed a bug?

Any insights would be appreciated.

TIA

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Ian Lance Taylor at Nov 13, 2013 at 2:35 pm

    On Wed, Nov 13, 2013 at 3:09 AM, Vincent Callanan wrote:
    However, if I replace readOnlyItem above with an anonymous struct.
    I get the following oddities:

    - My package compiles ok.
    - Importers of my package fail to compile with the following errors at the
    import line.

    unknown struct {} field 'mypackage.item' in struct literal
    tempname called with nil type

    Anonymous structs are so much cleaner in these situations and I cannot see
    why they shouldn't work.
    I have seen bug reports on the above errors, but they are not quite
    identical to the above scenario.

    If this is specified behaviour, should my package not fail to compile?
    Or is this indeed a bug?
    I don't think you showed the failing code, so I don't know if my
    comment is useful.

    In general a package can not use an unexported name from another
    package. That includes using it in a composite literal.

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Vincent Callanan at Nov 13, 2013 at 6:30 pm
    Thanks for the reply Ian,

    The whole point is that the code does not fail (and will compile okay) at
    package scope.
    However when I import the package into another, the importer will fail to
    compile with the above errors.
    ..and the line number of the compile errors corresponds to the import
    statement (hardly due to an import side-effect?).

    The compile fail only occurs when the GetItem() method above is changed
    thus:

    func myfunc() GetItem() struct {*item} {
         return struct{*item} {&myitem}
    }

    Apropos your general comment:

    Returning an unexported type works fine and has its uses.
    Should an anonymous struct not serve the same purpose?

    I can live with having to explicitly declare my "wrapper types" although it
    can get a little tedious.
    I just want to be clear that this limitation is as intended.
    And if it is intended, should the compiler not produce an error at source
    when compiling the package.
    As things stand, the error only gets caught when the importing package is
    compiled.

    Cheers,
    Vincent

    On Wednesday, 13 November 2013 14:35:19 UTC, Ian Lance Taylor wrote:
    On Wed, Nov 13, 2013 at 3:09 AM, Vincent Callanan wrote:

    However, if I replace readOnlyItem above with an anonymous struct.
    I get the following oddities:

    - My package compiles ok.
    - Importers of my package fail to compile with the following errors at the
    import line.

    unknown struct {} field 'mypackage.item' in struct literal
    tempname called with nil type

    Anonymous structs are so much cleaner in these situations and I cannot see
    why they shouldn't work.
    I have seen bug reports on the above errors, but they are not quite
    identical to the above scenario.

    If this is specified behaviour, should my package not fail to compile?
    Or is this indeed a bug?
    I don't think you showed the failing code, so I don't know if my
    comment is useful.

    In general a package can not use an unexported name from another
    package. That includes using it in a composite literal.

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Nov 13, 2013 at 8:56 pm

    On Wednesday, November 13, 2013 11:30:44 AM UTC-7, Vincent Callanan wrote:
    func myfunc() GetItem() struct {*item} {
    return struct{*item} {&myitem}
    }
    That's not valid method definition syntax.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at Nov 13, 2013 at 11:32 pm

    On Wed, Nov 13, 2013 at 10:30 AM, Vincent Callanan wrote:
    The whole point is that the code does not fail (and will compile okay) at
    package scope.
    However when I import the package into another, the importer will fail to
    compile with the above errors.
    ..and the line number of the compile errors corresponds to the import
    statement (hardly due to an import side-effect?).

    The compile fail only occurs when the GetItem() method above is changed
    thus:

    func myfunc() GetItem() struct {*item} {
    return struct{*item} {&myitem}
    }

    Apropos your general comment:

    Returning an unexported type works fine and has its uses.
    Should an anonymous struct not serve the same purpose?
    I'm sorry, I'm confused about just what you mean. Show us the code
    that fails.

    It is certainly intended that the name "item" in package A does not
    refer to the name "item" in package B.

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Vincent Callanan at Nov 13, 2013 at 11:47 pm
    Sincere apologies, lost in translation

    Should be....

    // this compiles and runs okay
    // in both source and importing packages

    func GetItem() readOnlyItem {
         return readOnlyItem {&myitem}
    }


    // this compiles ok in source package
    // but generates compile error in importing package
    // as described previously

    func GetItem() struct {*item} {
         return struct{*item} {&myitem}
    }

    On Wednesday, 13 November 2013 23:32:54 UTC, Ian Lance Taylor wrote:
    On Wed, Nov 13, 2013 at 10:30 AM, Vincent Callanan wrote:

    The whole point is that the code does not fail (and will compile okay) at
    package scope.
    However when I import the package into another, the importer will fail to
    compile with the above errors.
    ..and the line number of the compile errors corresponds to the import
    statement (hardly due to an import side-effect?).

    The compile fail only occurs when the GetItem() method above is changed
    thus:

    func myfunc() GetItem() struct {*item} {
    return struct{*item} {&myitem}
    }

    Apropos your general comment:

    Returning an unexported type works fine and has its uses.
    Should an anonymous struct not serve the same purpose?
    I'm sorry, I'm confused about just what you mean. Show us the code
    that fails.

    It is certainly intended that the name "item" in package A does not
    refer to the name "item" in package B.

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Vincent Callanan at Nov 14, 2013 at 12:20 am
    Just to be sure, here's a direct paste of the version that works....

    package pkgA

    type item struct {
    val int
    }

    type ReadOnlyItem struct {
    *item
    }

    func (this *item) Val() int {
    return this.val
    }

    func GetItem() ReadOnlyItem {
    return ReadOnlyItem{&item{1234}}
    }
    -----------------------------------------------

    package main

    import (
    "....../pkgA"
    "fmt"
    )

    func main() {
    fmt.Println(pkgA.GetItem().Val())
    }

    ------------------------------------------

    But when I replace func GetItem() in pkgA with

    func GetItem() struct{ *item } {
    return struct{ *item }{&item{1234}}
    }

    pkgA compiles ok, but I get the following compile error in package main at
    the import "pkgA" line:

    unknown struct {} field 'pkgA.item' in struct literal

    I hope this clarifies the problem and apologies for not being clear from
    the start

    cheers,
    Vincent
    On Wednesday, 13 November 2013 23:47:24 UTC, Vincent Callanan wrote:

    Sincere apologies, lost in translation

    Should be....

    // this compiles and runs okay
    // in both source and importing packages

    func GetItem() readOnlyItem {
    return readOnlyItem {&myitem}
    }


    // this compiles ok in source package
    // but generates compile error in importing package
    // as described previously

    func GetItem() struct {*item} {
    return struct{*item} {&myitem}
    }

    On Wednesday, 13 November 2013 23:32:54 UTC, Ian Lance Taylor wrote:

    On Wed, Nov 13, 2013 at 10:30 AM, Vincent Callanan <vin...@callanan.ie>
    wrote:
    The whole point is that the code does not fail (and will compile okay) at
    package scope.
    However when I import the package into another, the importer will fail to
    compile with the above errors.
    ..and the line number of the compile errors corresponds to the import
    statement (hardly due to an import side-effect?).

    The compile fail only occurs when the GetItem() method above is changed
    thus:

    func myfunc() GetItem() struct {*item} {
    return struct{*item} {&myitem}
    }

    Apropos your general comment:

    Returning an unexported type works fine and has its uses.
    Should an anonymous struct not serve the same purpose?
    I'm sorry, I'm confused about just what you mean. Show us the code
    that fails.

    It is certainly intended that the name "item" in package A does not
    refer to the name "item" in package B.

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Edwin Castro at Nov 14, 2013 at 12:49 am

    On 11/13/13, 4:20 PM, Vincent Callanan wrote:
    unknown struct {} field 'pkgA.item' in struct literal
    Isn't this error telling you that pkgA.item is not an exported name?

    --
    Edwin

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at Nov 14, 2013 at 12:56 am

    On Wed, Nov 13, 2013 at 4:20 PM, Vincent Callanan wrote:
    I hope this clarifies the problem and apologies for not being clear from the
    start
    Yes, thanks. Getting an error on the import line makes this sound
    like a bug.

    But I can't recreate it myself. What version of Go are you running?
    It looks a bit like http://golang.org/issue/2687 , but that was fixed
    long ago.

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Vincent Callanan at Nov 14, 2013 at 1:29 am
    Yes, I saw that bug but it was fixed in January 2012, so I ignored it.
    But the fact that you cannot reproduce my problem now indicates that maybe
    it has been fixed recently

    My go version is returning:
    go version go1.1.1 windows/amd64 (circa June 2013)

    Problem is that I have hybrid AppEngine/Standard dev env and have been slow
    about updating, hoping to make the great leap with 1.2 :-)

    I'll just have to bite the bullet tomorrow and report back.
    In any case, it's good to know that using anonymous struct wrappers is
    perfectly feasible in the way I suggested.

    Thanks all,
    Vincent

    On Thursday, 14 November 2013 00:56:13 UTC, Ian Lance Taylor wrote:
    On Wed, Nov 13, 2013 at 4:20 PM, Vincent Callanan wrote:

    I hope this clarifies the problem and apologies for not being clear from the
    start
    Yes, thanks. Getting an error on the import line makes this sound
    like a bug.

    But I can't recreate it myself. What version of Go are you running?
    It looks a bit like http://golang.org/issue/2687 , but that was fixed
    long ago.

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Vincent Callanan at Nov 15, 2013 at 10:50 pm
    Ok, the problem is still there in go version: go1.1.2 windows/amd64
    The fact that you (Ian) could not reproduce it may indicate that it is a
    platform-specific issue?
    In any case, I am generating a bug report.
    On Thursday, 14 November 2013 01:28:11 UTC, Vincent Callanan wrote:

    Yes, I saw that bug but it was fixed in January 2012, so I ignored it.
    But the fact that you cannot reproduce my problem now indicates that maybe
    it has been fixed recently

    My go version is returning:
    go version go1.1.1 windows/amd64 (circa June 2013)

    Problem is that I have hybrid AppEngine/Standard dev env and have been
    slow about updating, hoping to make the great leap with 1.2 :-)

    I'll just have to bite the bullet tomorrow and report back.
    In any case, it's good to know that using anonymous struct wrappers is
    perfectly feasible in the way I suggested.

    Thanks all,
    Vincent

    On Thursday, 14 November 2013 00:56:13 UTC, Ian Lance Taylor wrote:

    On Wed, Nov 13, 2013 at 4:20 PM, Vincent Callanan <vin...@callanan.ie>
    wrote:
    I hope this clarifies the problem and apologies for not being clear from the
    start
    Yes, thanks. Getting an error on the import line makes this sound
    like a bug.

    But I can't recreate it myself. What version of Go are you running?
    It looks a bit like http://golang.org/issue/2687 , but that was fixed
    long ago.

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Vincent Callanan at Nov 15, 2013 at 11:11 pm
    https://code.google.com/p/go/issues/detail?id=6773

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Carlos Castillo at Nov 16, 2013 at 5:59 am
    Have you tried against the most recent version of Go (1.2rc4)? Either that
    or tip would likely be what Ian ran his tests against.
    On Friday, November 15, 2013 2:50:51 PM UTC-8, Vincent Callanan wrote:

    Ok, the problem is still there in go version: go1.1.2 windows/amd64
    The fact that you (Ian) could not reproduce it may indicate that it is a
    platform-specific issue?
    In any case, I am generating a bug report.
    On Thursday, 14 November 2013 01:28:11 UTC, Vincent Callanan wrote:

    Yes, I saw that bug but it was fixed in January 2012, so I ignored it.
    But the fact that you cannot reproduce my problem now indicates that
    maybe it has been fixed recently

    My go version is returning:
    go version go1.1.1 windows/amd64 (circa June 2013)

    Problem is that I have hybrid AppEngine/Standard dev env and have been
    slow about updating, hoping to make the great leap with 1.2 :-)

    I'll just have to bite the bullet tomorrow and report back.
    In any case, it's good to know that using anonymous struct wrappers is
    perfectly feasible in the way I suggested.

    Thanks all,
    Vincent

    On Thursday, 14 November 2013 00:56:13 UTC, Ian Lance Taylor wrote:

    On Wed, Nov 13, 2013 at 4:20 PM, Vincent Callanan <vin...@callanan.ie>
    wrote:
    I hope this clarifies the problem and apologies for not being clear from the
    start
    Yes, thanks. Getting an error on the import line makes this sound
    like a bug.

    But I can't recreate it myself. What version of Go are you running?
    It looks a bit like http://golang.org/issue/2687 , but that was fixed
    long ago.

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Vincent Callanan at Nov 16, 2013 at 9:24 am
    Network glitch (this may be a duplicate).
    1.2rc4 compiles okay
    Thanks
    On Saturday, 16 November 2013 05:59:15 UTC, Carlos Castillo wrote:

    Have you tried against the most recent version of Go (1.2rc4)? Either that
    or tip would likely be what Ian ran his tests against.
    On Friday, November 15, 2013 2:50:51 PM UTC-8, Vincent Callanan wrote:

    Ok, the problem is still there in go version: go1.1.2 windows/amd64
    The fact that you (Ian) could not reproduce it may indicate that it is a
    platform-specific issue?
    In any case, I am generating a bug report.
    On Thursday, 14 November 2013 01:28:11 UTC, Vincent Callanan wrote:

    Yes, I saw that bug but it was fixed in January 2012, so I ignored it.
    But the fact that you cannot reproduce my problem now indicates that
    maybe it has been fixed recently

    My go version is returning:
    go version go1.1.1 windows/amd64 (circa June 2013)

    Problem is that I have hybrid AppEngine/Standard dev env and have been
    slow about updating, hoping to make the great leap with 1.2 :-)

    I'll just have to bite the bullet tomorrow and report back.
    In any case, it's good to know that using anonymous struct wrappers is
    perfectly feasible in the way I suggested.

    Thanks all,
    Vincent

    On Thursday, 14 November 2013 00:56:13 UTC, Ian Lance Taylor wrote:

    On Wed, Nov 13, 2013 at 4:20 PM, Vincent Callanan <vin...@callanan.ie>
    wrote:
    I hope this clarifies the problem and apologies for not being clear from the
    start
    Yes, thanks. Getting an error on the import line makes this sound
    like a bug.

    But I can't recreate it myself. What version of Go are you running?
    It looks a bit like http://golang.org/issue/2687 , but that was fixed
    long ago.

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 13, '13 at 11:09a
activeNov 16, '13 at 9:24a
posts14
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase