In this PR we address the need for a better Response type and split the representation of responses based on what kind of response they are, encoding this right into the type system. We are still not completely happy with how error responses are handled in this, however that can be further refined in a future PR or via the review notes of this PR.
This is to be considered a correctional PR between the ones for the remote protocol support.
The main aim with this PR is to have one type for when a response comes back OK from the probe, another for when it represents a parameter error, another for general errors, etc.. each specialised to have only the kinds of value conversions and such that are appropriate to what they represent. This makes it so it is impossible to call the wrong kind of value conversion on a given response.
Once merged, the branch this is on should not be deleted as there are an additional 2 PRs to go in the remote protocol series.
In this PR we address the need for a better Response type and split the representation of responses based on what kind of response they are, encoding this right into the type system. We are still not completely happy with how error responses are handled in this, however that can be further refined in a future PR or via the review notes of this PR.
This is to be considered a correctional PR between the ones for the remote protocol support.
The main aim with this PR is to have one type for when a response comes back OK from the probe, another for when it represents a parameter error, another for general errors, etc.. each specialised to have only the kinds of value conversions and such that are appropriate to what they represent. This makes it so it is impossible to call the wrong kind of value conversion on a given response.
Once merged, the branch this is on should not be deleted as there are an additional 2 PRs to go in the remote protocol series.