FAQ
LGTM except for array size bit




https://codereview.appspot.com/6903048/diff/21003/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/6903048/diff/21003/doc/go_spec.html#newcode839
doc/go_spec.html:839: array length further, but it must always permit at
least <code>int32</code> values.
I am not sure about this. If it is an array of large things, 8g is not
going to let you declare many of them. For example:

type T struct [ [1<<20]byte }
var x [1<<20]T

is not okay.

I think it would be fine not to set a lower bound and say

An implementation may restrict the maximum permissible array length.
For instance, the maximum size of an array type may be restricted by the
size of the target's virtual address space.

https://codereview.appspot.com/6903048/diff/21003/doc/go_spec.html#newcode840
doc/go_spec.html:840: For instance, on a 64bit platform, the maximum
length may be restricted by the size
64-bit

https://codereview.appspot.com/6903048/

Search Discussions

  • Gri at Dec 11, 2012 at 5:49 pm
    PTAL


    https://codereview.appspot.com/6903048/diff/21003/doc/go_spec.html
    File doc/go_spec.html (right):

    https://codereview.appspot.com/6903048/diff/21003/doc/go_spec.html#newcode839
    doc/go_spec.html:839: array length further, but it must always permit at
    least <code>int32</code> values.
    On 2012/12/11 15:53:08, rsc wrote:
    I am not sure about this. If it is an array of large things, 8g is not going to
    let you declare many of them. For example:
    type T struct [ [1<<20]byte }
    var x [1<<20]T
    is not okay.
    I think it would be fine not to set a lower bound and say
    An implementation may restrict the maximum permissible array length.
    For instance, the maximum size of an array type may be restricted by the
    size of the target's virtual address space.
    This is essentially what I had at first. Reverted.

    https://codereview.appspot.com/6903048/diff/21003/doc/go_spec.html#newcode840
    doc/go_spec.html:840: For instance, on a 64bit platform, the maximum
    length may be restricted by the size
    On 2012/12/11 15:53:08, rsc wrote:
    64-bit
    ACK

    https://codereview.appspot.com/6903048/
  • Iant at Dec 11, 2012 at 6:12 pm
    https://codereview.appspot.com/6903048/diff/18002/doc/go_spec.html
    File doc/go_spec.html (right):

    https://codereview.appspot.com/6903048/diff/18002/doc/go_spec.html#newcode840
    doc/go_spec.html:840: For instance, the maximum size of an array type
    may be restricted by
    But now you are back to not setting a lower bound. That was my original
    complaint, and rsc mentioned it also.

    https://codereview.appspot.com/6903048/
  • Russ Cox at Dec 11, 2012 at 6:34 pm
    Ian, do you have any suggestions on the lower bound? In general if the
    element size is large enough the lower bound might be 1.
  • Robert Griesemer at Dec 11, 2012 at 6:38 pm
    I think not setting a lower bound is fine. I added the restriction
    such that implementations are free to enforce sensible restrictions
    (such as gc does now) and don't have to resort to some kind of runtime
    error. If an implementation interprets the absence of a lower bound as
    "the maximum permitted size is 10 elements" that's fine too - but
    nobody is going to take that compiler serious...

    - gri
    On Tue, Dec 11, 2012 at 10:27 AM, Russ Cox wrote:
    Ian, do you have any suggestions on the lower bound? In general if the
    element size is large enough the lower bound might be 1.
  • Iant at Dec 11, 2012 at 6:35 pm
    I still think we should have a lower bound, as we do in our other
    implementation restrictions.

    "Implementation restriction: an implementation may restrict the maximum
    permissible array length. For instance, the maximum size of an array
    type may be restricted by the size of the target's virtual address
    space. That said, every implementation must support arrays for which
    unsafe.Sizeof applied to a value of the array type will return less than
    1073741824 (1G)."

    https://codereview.appspot.com/6903048/
  • R at Dec 11, 2012 at 6:36 pm
    https://codereview.appspot.com/6903048/diff/18002/doc/go_spec.html
    File doc/go_spec.html (right):

    https://codereview.appspot.com/6903048/diff/18002/doc/go_spec.html#newcode820
    doc/go_spec.html:820: of type <code>int</code>.
    "representable by a value of type int" is sort of a category error. a
    value is a value; it's not representing anything. i think you mean
    stored in a variable of type int, but that sounds wrong, and the same
    glitch occurs elsewhere. you've added a lot more instances of this, so
    let's clean it up everywhere.

    since a type represents a range of values (we've used that idea when
    introducing types), how about just 'representable by an int'? or maybe
    'in the range of the int type'?

    https://codereview.appspot.com/6903048/diff/18002/doc/go_spec.html#newcode840
    doc/go_spec.html:840: For instance, the maximum size of an array type
    may be restricted by
    what is this clause trying to achieve, exactly? a compile-time
    constraint? a run-time-constraint? mere ass-covering?

    https://codereview.appspot.com/6903048/
  • Russ Cox at Dec 11, 2012 at 6:49 pm
    what is this clause trying to achieve
    Ian wants to make sure that implementations can reject
    [1<<20][1<<20][1<<20]byte (no current machine can store one of those
    in its virtual address space) but that they cannot reject
    [5][5][5]byte.
  • Gri at Dec 11, 2012 at 7:32 pm
    No changes but some feedback.


    https://codereview.appspot.com/6903048/diff/18002/doc/go_spec.html
    File doc/go_spec.html (right):

    https://codereview.appspot.com/6903048/diff/18002/doc/go_spec.html#newcode820
    doc/go_spec.html:820: of type <code>int</code>.
    On 2012/12/11 18:36:30, r wrote:
    "representable by a value of type int" is sort of a category error. a
    value is a
    value; it's not representing anything. i think you mean stored in a
    variable of
    type int, but that sounds wrong, and the same glitch occurs elsewhere. you've
    added a lot more instances of this, so let's clean it up everywhere.
    since a type represents a range of values (we've used that idea when
    introducing
    types), how about just 'representable by an int'? or maybe 'in the
    range of the
    int type'?
    I am fine with changing this, but:

    a) what you are suggesting is close to what I had at first, and iant
    objected;
    b) we are using the current phrase "representable by a value of type T"
    elsewhere fairly consistently (see Assignability, Conversions, Constant
    expressions, etc.).

    (The notions of "representable as a value of type int", "integer value",
    "value of integer type", and "value of int type" are all very similar in
    English, but they all mean different things in the spec. It's probably
    worthwhile making the nomenclature clear in the spec at some point but
    not in this CL).

    https://codereview.appspot.com/6903048/diff/18002/doc/go_spec.html#newcode840
    doc/go_spec.html:840: For instance, the maximum size of an array type
    may be restricted by
    On 2012/12/11 18:12:35, iant wrote:
    But now you are back to not setting a lower bound. That was my original
    complaint, and rsc mentioned it also.
    quoting rsc: "I think it would be fine not to set a lower bound and
    say..."
    (what I have written now).

    https://codereview.appspot.com/6903048/diff/18002/doc/go_spec.html#newcode840
    doc/go_spec.html:840: For instance, the maximum size of an array type
    may be restricted by
    On 2012/12/11 18:36:30, r wrote:
    what is this clause trying to achieve, exactly? a compile-time
    constraint? a
    run-time-constraint? mere ass-covering?
    It is a compile-time constraint currently implemented by 6g. The clause
    is merely permitting an implementation to have such a constraint (rather
    than having to resort to some other error - say out of memory, at
    run-time). So yes, "ass-covering"...

    https://codereview.appspot.com/6903048/
  • Iant at Dec 11, 2012 at 7:50 pm
    FYI


    https://codereview.appspot.com/6903048/diff/18002/doc/go_spec.html
    File doc/go_spec.html (right):

    https://codereview.appspot.com/6903048/diff/18002/doc/go_spec.html#newcode820
    doc/go_spec.html:820: of type <code>int</code>.
    On 2012/12/11 19:32:55, gri wrote:
    On 2012/12/11 18:36:30, r wrote:
    "representable by a value of type int" is sort of a category error.
    a value is
    a
    value; it's not representing anything. i think you mean stored in a
    variable
    of
    type int, but that sounds wrong, and the same glitch occurs
    elsewhere. you've
    added a lot more instances of this, so let's clean it up everywhere.

    since a type represents a range of values (we've used that idea when
    introducing
    types), how about just 'representable by an int'? or maybe 'in the
    range of
    the
    int type'?
    I am fine with changing this, but:
    a) what you are suggesting is close to what I had at first, and iant objected;
    b) we are using the current phrase "representable by a value of type T"
    elsewhere fairly consistently (see Assignability, Conversions, Constant
    expressions, etc.).
    (The notions of "representable as a value of type int", "integer
    value", "value
    of integer type", and "value of int type" are all very similar in
    English, but
    they all mean different things in the spec. It's probably worthwhile
    making the
    nomenclature clear in the spec at some point but not in this CL).
    I objected mainly because of the inconsistency: I saw that other places
    in the spec used different wording to express the concept, and I thought
    that we should use that same wording in this CL. If you change the rest
    of the spec to use some new wording, I'm OK with that.

    I would normally say something like "the constant must be representable
    in the type int" but I want the spec to be consistent in the words used
    for this concept.

    https://codereview.appspot.com/6903048/diff/18002/doc/go_spec.html#newcode840
    doc/go_spec.html:840: For instance, the maximum size of an array type
    may be restricted by
    On 2012/12/11 19:32:55, gri wrote:
    On 2012/12/11 18:12:35, iant wrote:
    But now you are back to not setting a lower bound. That was my
    original
    complaint, and rsc mentioned it also.
    quoting rsc: "I think it would be fine not to set a lower bound and say..."
    (what I have written now).

    Sorry, you're quite right, I did misread rsc.

    But if we permit the implementation to have an upper bound I still want
    a lower bound.

    https://codereview.appspot.com/6903048/
  • Robert Griesemer at Dec 11, 2012 at 8:02 pm
    Specific wording aside, it sounds like everybody is ok with the actual
    content of the proposed change (array/slice sizes/indices must fit
    into int). If so, I can update/remove some of the issues filed. I'll
    take silence as a yes...

    Apropos the implementation restriction: perhaps I should just remove it.
    - gri

    On Tue, Dec 11, 2012 at 11:50 AM, wrote:
    FYI



    https://codereview.appspot.com/6903048/diff/18002/doc/go_spec.html
    File doc/go_spec.html (right):

    https://codereview.appspot.com/6903048/diff/18002/doc/go_spec.html#newcode820
    doc/go_spec.html:820: of type <code>int</code>.
    On 2012/12/11 19:32:55, gri wrote:
    On 2012/12/11 18:36:30, r wrote:
    "representable by a value of type int" is sort of a category error.
    a value is
    a
    value; it's not representing anything. i think you mean stored in a
    variable
    of
    type int, but that sounds wrong, and the same glitch occurs
    elsewhere. you've
    added a lot more instances of this, so let's clean it up everywhere.

    since a type represents a range of values (we've used that idea when
    introducing
    types), how about just 'representable by an int'? or maybe 'in the
    range of
    the
    int type'?
    I am fine with changing this, but:
    a) what you are suggesting is close to what I had at first, and iant objected;
    b) we are using the current phrase "representable by a value of type T"
    elsewhere fairly consistently (see Assignability, Conversions, Constant
    expressions, etc.).
    (The notions of "representable as a value of type int", "integer
    value", "value
    of integer type", and "value of int type" are all very similar in
    English, but
    they all mean different things in the spec. It's probably worthwhile
    making the
    nomenclature clear in the spec at some point but not in this CL).

    I objected mainly because of the inconsistency: I saw that other places
    in the spec used different wording to express the concept, and I thought
    that we should use that same wording in this CL. If you change the rest
    of the spec to use some new wording, I'm OK with that.

    I would normally say something like "the constant must be representable
    in the type int" but I want the spec to be consistent in the words used
    for this concept.


    https://codereview.appspot.com/6903048/diff/18002/doc/go_spec.html#newcode840
    doc/go_spec.html:840: For instance, the maximum size of an array type
    may be restricted by
    On 2012/12/11 19:32:55, gri wrote:
    On 2012/12/11 18:12:35, iant wrote:
    But now you are back to not setting a lower bound. That was my
    original
    complaint, and rsc mentioned it also.
    quoting rsc: "I think it would be fine not to set a lower bound and say..."
    (what I have written now).


    Sorry, you're quite right, I did misread rsc.

    But if we permit the implementation to have an upper bound I still want
    a lower bound.

    https://codereview.appspot.com/6903048/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedDec 11, '12 at 3:53p
activeDec 11, '12 at 8:02p
posts11
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase