Ticket #1421 (new RFC)

Opened 12 years ago

Last modified 11 years ago

[RFC] zero length FxA behaviour

Reported by: plobsing Owned by: plobsing
Priority: normal Milestone:
Component: none Version: 2.0.0
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:

Description

FixedBooleanArray, FixedStringArray, FixedIntegerArray, and FixedFloatArray do not allow specifying a length of 0, giving a misleading error of "Fixed${type}Array: can't resize".

FixedPMCArray ignores being set to zero length, remaining uninitialized.

Allowing for zero lengthed arrays allows code that handles "0 or more elements" cases to avoid checking against the zero case. For example:

.sub 'fixed_ints_upto'
    .param int i
    .local pmc retv
    retv = new ['FixedIntegerArray']
    retv = i
    $I0 = 0
    loop:
         if $I0 >= i goto end_loop:
         retv[$I0] = $I0
         inc $I0
         goto loop
    end_loop:

    .return (retv)
.end

This will currently fail. To avoid failures, we would have to check for a zero valued argument and handle that case separately.

Zero is a valid length for an array, so I propose that we allow FxAs to be set to zero length (and not be subsequently resizable).

Alternatively, the behaviour could be to ignore setting the length to zero (as is done now in FPA). However, this can be seen as violating the set once property of FxA length.

Change History

Changed 11 years ago by bacek

Hello.

I would like to reject this RFC. We have .init_int now and example can be rewritten as retv = new ['FixedIntegerArray'], i which DTRT. If some of *Arrays doesn't support it we should just fix them.

-- Bacek.

Changed 11 years ago by kurahaupo

The point about this isn't that size is set separately, it's that zero should be treated as a valid length, and not as a sentinel for "not set yet".

As it stands, setting the length of an FxA to zero has insufficent effect, whether you do it by passing the length to the constructor, or by setting it afterwards.

We shouldn't just do nothing; if zero-length is deemed invalid, then setting it should throw an exception rather than silently ignore the change.

Changed 11 years ago by cotto

How about assigning some hard-coded non-pointer value (call it FxA_UNINITIALIZED) to the pointer used for storing the array's values until it's initialized? The F*A code would need some updates to check for FxA_UNINITIALIZED instead of looking at the size, but that should provide a reasonable solution.

Changed 11 years ago by NotFound

I like that idea.

But the main point, implementation details apart, is to decide if we want to change the current behavior, and in that case add a deprecation notice and document the new one.

Note: See TracTickets for help on using tickets.