Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update documentation of bitmask types that they does not have to be always prefixed #618

Closed
mikir opened this issue May 21, 2024 Discussed in #617 · 0 comments
Closed
Assignees
Labels
documentation Documentation change is needed enhancement New feature or request
Milestone

Comments

@mikir
Copy link
Contributor

mikir commented May 21, 2024

Discussed in #617

Originally posted by Danaozhong May 19, 2024
The zserio specification about bitmasks states the following:

In expressions outside of the defining type, bitmask values must always be prefixed by the type name and a dot, e.g. Permission.WRITABLE.

This doesn't seem to apply to the isset() operator, as the example provided shows that writing the following is possible:
return isset(testBitmask, INT);
This example also compiles with zserio (tested version 2.11.0).
This code does not compile:
return ((testBitmask & INT) == TestBitmask.INT);

The isset() example is not within the defining type, but omits the type name and dot. Based on the documentation of bitmask types, I would have expected only the following syntax to be legal:
return isset(testBitmask, TestBitmask.INT);

That feels a bit inconsistent to me. Of course, it makes sense that isset() can deduce the bitmask type from the first operand, but it seems to contradict the documentation.

@mikir mikir added enhancement New feature or request documentation Documentation change is needed labels May 21, 2024
@mikir mikir added this to the 2.15 milestone May 21, 2024
@mikir mikir self-assigned this Aug 12, 2024
@mikir mikir closed this as completed Sep 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Documentation change is needed enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant