Added syntax derived from Stefan Teleman's #446 #450
Conversation
source/language/types.rst
Outdated
| element type supports direct initialization from such a type. | ||
|
|
||
| It is unspecified whether the memory allocation of an array is of static storage | ||
| duration, or it is obtained via dynamic allocation. This property is implementation |
There was a problem hiding this comment.
I'm confused by the word "duration" here. Would it be okay to say "it is unspecified whether the memory allocation of the an array is static or obtained via dynamic allocation"?
There was a problem hiding this comment.
The Standardese / Officialese term for memory storage obtained via stack allocation is static storage duration.
It's static because, well, it's not dynamic (as in malloc(3C ) and friends).
Duration in this context refers to the amount of time the allocated memory block is alive - meaning in scope. static storage duration means the allocation is alive for as long as the object is in scope, and it gets automatically reclaimed by the operating system when the object goes out of scope.
As opposed to dynamic allocation, where the allocated memory block is - in principle - alive for the entire duration of the program, unless the program itself releases it back to the operating system.
There was a problem hiding this comment.
Added language per this discussion
Co-authored-by: Blake Johnson <blakejohnson04@gmail.com>
source/language/types.rst
Outdated
| Partial initialization via initializer list is allowed - i.e. the initializer | ||
| list is incomplete, and does not provide values for all the elements of the array. | ||
| In this case, the elements that are not initialized via initializer list are not | ||
| initialized, and their values are undefined. |
There was a problem hiding this comment.
Its unclear if partial initialization is permitted here only for the outer list or if partial inner dimensions are allowed too. Ie it seems clear that I can do:
array[int [8], 3, 2] arr = {{1, 2}}; // arr={{1, 2}, {?, ?}, {?, ?}}
but can I also do staggered partial initialization?
array[int [8], 3, 2] arr = {{}, {1,2}, {3}}; // arr={{?, ?}, {1, 2}, {3, ?}}
This seems a bit weird?
source/language/types.rst
Outdated
| It is unspecified whether the memory allocation of an array is of static storage | ||
| duration, (meaning the allocation is alive for as long as the object is in scope and | ||
| gets automatically reclaimed by the runtime when the object goes out of scope) | ||
| or it is obtained via dynamic allocation (meaning the allocation persists through the lifetime | ||
| of the program, unless the program itself releases it back to the operating system). | ||
| This property is implementation dependent. | ||
|
|
||
| If the array memory is obtained via dynamic allocation, the implementation is | ||
| responsible for reclaiming the memory when the array object goes out of scope | ||
| (garbage collection). |
There was a problem hiding this comment.
Since all arrays are declared in global scope maybe the real question is whether the compiler chooses to do lifetime analysis and only allocate the array (some time before) when it is first used and deallocate (some time after) the last usage?
source/language/types.rst
Outdated
| As a special case, a direct initializer list declaration of the form: | ||
|
|
||
| ``array[<type>, <size>] <identifier> = { <X> };`` |
There was a problem hiding this comment.
I can see value in having syntax for initializing all elements to the same value, but this special case syntax that overlaps with the partial-initialization syntax seems unnecessary. (Especially since I imagine the most common form of partial initialization would be to initialize just the first element of say a list of accumulated deltas, which usage is precluded by this special case).
But maybe its ok since you can think of this as both partial initialization (where the unspecified elements happen to be initialized to X) and as constant initialization of the whole array. Assuming we don't care about the cost of initializing more than was needed maybe it's ok. Otherwise, maybe:
| As a special case, a direct initializer list declaration of the form: | |
| ``array[<type>, <size>] <identifier> = { <X> };`` | |
| As a special case, a direct initializer list declaration of the form: | |
| ``array[<type>=<X>, <size>] <identifier>;`` |
might be another option for constant initialization of the whole array?
There was a problem hiding this comment.
I'll chime in and say that I'm not a fan of supporting both partial initialization and the array[<type>, <size>] <identifier> = { <X> }; initialization above, for the reason that I think the semantics of partial initialization should be basically monotonic (more data specified the initializer list means more elements get initialized). Or to turn this around: it would come as a surprise to me (if I hadn't read the spec) that array[int, 5] = {3,2} has more undefined elements than array[int, 5] = {3}.
Co-authored-by: Lev Bishop <18673315+levbishop@users.noreply.github.com>
Co-authored-by: Lev Bishop <18673315+levbishop@users.noreply.github.com>
source/language/types.rst
Outdated
| As a special case, a direct initializer list declaration of the form: | ||
|
|
||
| ``array[<type>, <size>] <identifier> = { <X> };`` |
There was a problem hiding this comment.
I'll chime in and say that I'm not a fan of supporting both partial initialization and the array[<type>, <size>] <identifier> = { <X> }; initialization above, for the reason that I think the semantics of partial initialization should be basically monotonic (more data specified the initializer list means more elements get initialized). Or to turn this around: it would come as a surprise to me (if I hadn't read the spec) that array[int, 5] = {3,2} has more undefined elements than array[int, 5] = {3}.
source/language/types.rst
Outdated
| gets automatically reclaimed by the runtime when the object goes out of scope) | ||
| or it is obtained via dynamic allocation (meaning the allocation persists through the lifetime | ||
| of the program, unless the program itself releases it back to the operating system). | ||
| This property is implementation dependent. |
There was a problem hiding this comment.
It's not clear to me why this needs to be said. There's nothing here that I disagree with, but I just don't see how to operationalize it -- I don't know of any other part of the spec that talks about storage classes or memory management. It seems like a user just has no way of knowing the difference here, and so probably wouldn't care.
Clarify per TSC discussion 2023-08-02
Summary
Details and comments