FAQ
What are the Go developers thoughts about supporting per function/method
array/slice bounds checking? I guess a smart compiler could get rid of
many, but in some inner loops, when accessing multiple arrays/slices they
do hurt performance, while in general I like that Go does check them.

--
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

  • Maxim Khitrov at Sep 21, 2013 at 9:20 pm

    On Sat, Sep 21, 2013 at 4:44 PM, Erwin wrote:
    What are the Go developers thoughts about supporting per function/method
    array/slice bounds checking? I guess a smart compiler could get rid of many,
    but in some inner loops, when accessing multiple arrays/slices they do hurt
    performance, while in general I like that Go does check them.
    For slices you could have a per-variable solution by introducing
    syntax like [*]byte, meaning a []byte that skips all bounds checking.
    The distinction would only exist during compilation and you would be
    free to assign variables of one type to the other. It would be nice to
    have something like this for performance when used judiciously. One
    current option is just to use array pointers:

    https://groups.google.com/d/msg/golang-nuts/4tUmlpB7Rng/aKbTTsYNv-gJ

    --
    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.
  • Steven Blenkinsop at Sep 21, 2013 at 10:28 pm
    That seems incredibly unlikely to ever happen. It would basically mean the
    core language would no longer be memory safe (disregarding
    package unsafe and memory races in parallel code, which currently make Go
    not strictly memory safe).

    Somewhat more likely is the ability to convert/assert slices to array
    pointers, as in this issue:
    https://code.google.com/p/go/issues/detail?id=395

    As you can see, it's not a priority. However, since we can now shrink the
    cap on a slice, this wouldn't be the only cap-reducing feature, which
    removes one possible objection, since the notion of identifying the backing
    array of a slice by the address of the cap'th element is already gone.
    On Saturday, 21 September 2013, Maxim Khitrov wrote:

    On Sat, Sep 21, 2013 at 4:44 PM, Erwin <snesseird@gmail.com <javascript:;>>
    wrote:
    What are the Go developers thoughts about supporting per function/method
    array/slice bounds checking? I guess a smart compiler could get rid of many,
    but in some inner loops, when accessing multiple arrays/slices they do hurt
    performance, while in general I like that Go does check them.
    For slices you could have a per-variable solution by introducing
    syntax like [*]byte, meaning a []byte that skips all bounds checking.
    The distinction would only exist during compilation and you would be
    free to assign variables of one type to the other. It would be nice to
    have something like this for performance when used judiciously. One
    current option is just to use array pointers:

    https://groups.google.com/d/msg/golang-nuts/4tUmlpB7Rng/aKbTTsYNv-gJ

    --
    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 <javascript:;>.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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
postedSep 21, '13 at 8:44p
activeSep 21, '13 at 10:28p
posts3
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase