(many) Add implicitly typed int
arrays
#494
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an important step towards completing #487, but a few more things are needed for this:
int[]
as an explicit type specifier. Right now, only implicitly typedint
arrays are supported.long[]
,double[]
andstring[]
.As for the underlying
perlang::IntArray
class, what I am aiming for here is something a bit more high-level than traditional C-styleint[]
arrays. They are nice in the sense of being "low overhead" but are also prone to all kinds of C-style memory issues (heap overflow, most notably). Perlang arrays will be more akin to Java or C#-style arrays, which are inherently "safe by design". It should be more or less impossible to use a Perlang array in such a way as to cause the program to crash. Because we don't have a JVM or MSIL interpreter to help us with this, we have to implement the boundary checks on our own.At the moment, those boundary checks throw (C++) exceptions. We could consider adding more "try"-oriented methods too, like
try_get(index, default_value)
or eventry_get(index, () -> default_value)
if we want to be more fancy. Either way, the point is to avoid exceptions and let the caller (by returning abool
) check if the operation was successful or not by different, sometimes more appropriate means than exceptions.