Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] API Design Discussion: Enforcing null Checks with Optional

Hi everyone

 

In the wake of implementing and reviewing structured bindings [1][2] Nate and I had a quick discussion about the API design of public interfaces in CDT. A new interface will be introduced for representing structured binding AST nodes. In this interface we declare two methods that return objects/values that might be missing in the C++ source code and therefore require null checks on the call-side when using the corresponding node:

  • It  might contain a reference qualifier (& or &&), there is a method for retrieving it (getRefQualifier). This is optional by the standard.
  • While it is not valid by the standard, our parser gracefully accepts the omission of the initializer.

 

While the first case could be solved by just adding a further value to the RefQualifier enumeration (RefQualifier.NONE), the latter case requires a null-check (unless we introduce a NullInitializer AST node). So far we seemed to always just mention the need for a null check in the documentation of the interface. Since Java 8 we could alternatively state this need explicitly in the API by returning an Optional<IASTInitializer>. Is there any official guideline for API design regarding this aspect CDT follows?

I currently followed the Optional-approach for the structured bindings patch, but I would like to check back with the other committers before I submit it and make the API design inconsistent.

 

I’m looking forward to your comments!

 

Thomas

 

 

 

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=522200

[2] https://git.eclipse.org/r/c/126387/

 

Back to the top