Getting default value of type not currently possible when implementing codec about rasn

[XAMPPRocky]

But I don't mind if we just consider more optimisation here. I don't see many use cases why someone would want that error.

Yeah I think for now, let's leave it, we can still validate COER through our tests. I think is someone can provide a compelling use case, then we can change. Because right now, the other codecs do the same thing where if the value provided is the default, it's just passed along and we don't check.

[XAMPPRocky]

On same cases codec decoder might want to rise an error if the default is encoded as value when it should be omitted.

Is this a meaningful case? Like is there a case where it's better to present an error when presented with a value that matches the default?

[Nicceboy]

When looking the COER encoding rules, there is section:

31.9 In the encoding of a sequence or set type, each component that is marked DEFAULT shall be encoded as absent if its value is identical to the default value.

I am not sure how to handle this on decoder side, but I would assume that it is error if there is default value instead of omitting it.

[XAMPPRocky]

I am not sure how to handle this on decoder side, but I would assume that it is error if there is default value instead of omitting it.

I don't know if I would assume that, an encoder is supposed to omit it, but I feel like it's more intuitive for the decoder to accept, it's not like (correct me if I'm wrong), that we can take advantage of an optimisation here, because in order to know if it's the default value, we have to decode it anyway, and by that point we have already all the work.

[Nicceboy]

I don't know if I would assume that, an encoder is supposed to omit it, but I feel like it's more intuitive for the decoder to accept, it's not like (correct me if I'm wrong), that we can take advantage of an optimisation here, because in order to know if it's the default value, we have to decode it anyway, and by that point we have already all the work.

That is certaintly true from performance point.
I am trying to make distinction between OER and COER decoder (OER happily decodes defaults), so that what is left for COER is to strictly validate if the input is produced by COER encoder.

But I don't mind if we just consider more optimisation here. I don't see many use cases why someone would want that error.