[Feature request/idea] Optional parameters and choices.

[EotT123]

Optional parameters are a great alternative for traditional (step) builders. However, I think there's still room for improvement in expressiveness.

A common scenario I run into is when I have two or more parameters where I want exactly one of them to be provided. Making all of them optional doesn't quite fit, because that allows either none or all to be passed—neither of which is desirable in this case.

It would be great if Manifold could support this kind of mutual exclusivity. Here's a conceptual example:

public MyClass(Boolean foo | Integer bar, String test = "defaultValue") {
  // do something with it. Either 'foo' or 'bar' will be null.
}

This would allow the following valid usages:

new MyClass(foo: true, test: "testValue");
new MyClass(foo: true);
new MyClass(bar: 2, test: "testValue");
new MyClass(bar: 2);

But the following should result in a compile-time error:

new MyClass(foo: true, bar: 2);
new MyClass(foo: true, bar: 2,  test: "testValue");

For this simple case, I could define two separate constructors, one taking foo, and the other taking bar. However, as the number of mutually exclusive parameters increases, the number of required constructors grows exponentially. This quickly becomes unmanageable and error-prone.

[rsmckinney]

Interesting idea. Typically, this is done with union types. So, instead of having mutually exclusive parameters, you have a parameter with mutually exclusive types.

Boolean | Integer param

But, union types don't solve the case where mutually exclusive parameters have the same type. I think your idea covers that... although, a "mutually exclusive" type could be interesting here.

For now, though, I'm thinking mutually exclusive parameters can, mostly, be handled with overloads at compile time. Or, just handled at runtime with normal parameter checking. Definitely not as nice, but I don't think this tends to be the bottleneck for developer productivity or correctness. I could be wrong.

[EotT123]

In your example, the only distinction is the type of the parameter, while the parameter name remains unchanged. I would like to propose considering scenarios where both the parameter name and type differ. This approach offers several advantages:

• Ease of Use: Developers would not need to verify the type of the parameter within the method body; they would only need to check for non-nullness. This simplifies the implementation.
• Improved Expressiveness for Named Parameters: When parameter names reflect different concepts (beyond just differing types), it enhances the clarity and intent of the code. This can lead to better understanding and maintainability.

[rsmckinney]

Totally agree with you, I like the feature. But in practice, method overloading already covers at least 90% of the use cases.

Now, no one hates overloading more than I do. If I were designing a language from scratch, I’d go out of my way to avoid it. It bleeds into the compiler and type system in subtle, toxic ways. As a language creator and maintainer, I loathe it, it's poison. So yes, in a clean-slate language, I’d implement unions, mutually exclusive parameters, whatever it takes to sidestep overloading entirely.

But the cost of wedging this into Java via a language plugin--both at the compiler and IDE level--is beyond my comfort zone right now. The ROI just isn’t there. I'd rather invest in areas with higher leverage. Shrug.

[EotT123]

Fair enough. I can definitely see your point of view. I imagine it's not trivial to implement, especially with the added complexity of supporting optional parameters as well.

That said, it's still a very appealing feature from a usability perspective, and I thought it was worth bringing up. But it makes sense to focus your time on areas with more immediate impact.

[rsmckinney]

Yeah, I also see the value in it, which is why I’m leaving it open—I could see changing my mind :/

Thanks for another nice idea.