Similar to how we had juce::Optional as a placeholder for std::optional before moving to C++17, it’d be great to get a juce::Expected as a placeholder for std::expected before moving to C++23.
std::expected works very similarly to std::optional in that it either will or won’t hold a value of the specified type. The advantage of std::expected over std::optional however is that you can also specify an error type for when there’s no value to explain why there’s no value.
// Must use exceptions or assertions for error handling.
XmlElement download (URL url);
// Will return a nullopt if the download failed, but doesn't explain why.
std::optional<XmlElement> download (URL url);
enum class DownloadError
{
lostConnection,
invalidURL,
couldntBeBothered,
};
// If the download fails, you get an error value to explain why!
std::expected<XmlElement, DownloadError> download (URL url);
The monadic operators are especially useful (and would make a good addition to juce::Optional too as they’re not added to std::optional until C++23 either) as they allow you to handle errors in a very functional, declarative way:
download("https://myserver.com/somefile.xml")
.or_else(createEmptyXML)
.transform(toFile)
.and_then(displayFilepathToUser)
.or_else(displayErrorToUser);
// vs
auto xml = download("https://myserver.com/somefile.xml")
if (!xml.has_value())
xml = XmlElement{"Empty"};
auto file = writeToFile (*xml);
if (file.existsAsFile())
displayFilepathToUser(file);
else
displayErrorToUser(file);
It will take at least 5 years before the juce team will rewrite it properly, because the code there is not done by experienced enough developers to be included in the framework.
But I definitely agree that it would be great for more PRs to be accepted.
They did make a bit of progress towards it with the contributor agreements and they did actually accept a few PRs as evident by JUCE’s list of contributors on GitHub.
My sincere admiration for this contribution. I commend the achievement. It does come as a surprise that the JUCE team hasn’t undertaken a comprehensive rewrite, complete with updated documentation and thorough unit tests.
It appears that the level of hostility in this simple feature request thread mirrors the tension between the JUCE team and community contributions. It’s as if we’re witnessing a reflection of the larger struggle within the project itself.
But, hey, sometimes a bit of friction in discussions can be a reflection of the challenges faced in open-source collaboration, right? JUCE is an open-source blah blah... right ?
I never said that to you personally, what are you guys reading here ? You ironically started questioning my skills first man, so i answered on the line
Frankly, I’ve held back from contributing more PRs through my own forks because it seems like a futile effort. My earliest contributions to JUCE go way back, likely before you even knew how to walk. But over the years, things have gone downhill. Today, progress within the JUCE community is at a snail’s pace, and it’s disheartening to see the stagnation.
It’s painfully evident that the reFX and soundradix forks (and i’m pretty sure there are plenty others) are shining examples of substantial improvements that are shamefully ignored by the JUCE team. They’ve significantly boosted stability and added crucial features, yet it seems like the JUCE team treats them as if they’re not useful to the platform. The same sad story repeats itself with countless other contributions and ideas (like this one, a modern juce::Result, or the juce component inspector just to name another good one) – sure, they say it’s on their radar, but in reality, it’s as if the plane has crashed.
I can understand being frustrated with the JUCE team’s communication, but I don’t understand why that bitterness also seems to extend to other community members on here. Remarks like
We regularly receive feedback from JUCE users (usually beginners) telling us that the forum can feel intimidating, which, in turn, stops them contributing to the wider JUCE community. The JUCE forum is objectively a much more accommodating place than many other online forums, but the bar there is particularly low. We have an established history of suspending people’s accounts and it should come as no surprise that the JUCE team is 100% committed to creating an environment which is as inclusive as possible and encourages everyone to become a part of it.
This thread has gone sideways from the original post and now, unfortunately, needs a message like this to show that the behaviour here should not be repeated.
If the hostile attitude in this thread is continued, or repeated elsewhere, the authors of any offending messages will have their accounts silenced. Please consider this a warning.
