3 ms·
That looks like something I'd have concocted 20 years ago. Oh yeah let's chain expressions with functors in order to wrap the behaviour of a simple if statement
by nurettin 3y ago
That looks like something I'd have concocted 20 years ago. Oh yeah let's chain expressions with functors in order to wrap the behaviour of a simple if statement. Campus party at 8.
- throw156754228 3y agoMore categorical solutions looking for a problem.
- pjmlp 3y agoHardly anything new to anyone using ML or Lisp derived languages for the last half century, it is still quite new concept for most folks, specially in languages like C++.
- mmoll 3y agoThe idea is to make the accesses safer, not necessarily more readable. The monadic operations make it impossible to access the value in a std::optional without first testing that it actually contains a value.
- nurettin 3y agoI understand the value of enforcing behaviours with types, but experience has taught me that this is a tooling issue, not something you have to wrap into a spaghetti mess every time you want to code an if. Example: While programming kotlin, intellij idea warned me whenever I accessed a nullable object without a null check, and gave suggestions to convert types to non-nullable in order to avoid the checks altogether whenever appropriate. I think there is value in keeping the code clean while keeping it correct at the same time, but that should be done at the compiler or linter level.
- mmoll 3y agoBut code using these monadic operations can also be quite clean… toy example: auto askForUsername = [&] { … }; auto lookupUserByName = [&](auto name) { … }; auto printUserDetails = [&](auto userId) { … }; auto details = askForUsername() .and_then(lookupUserByName) .and_then(printUserDetails);
- deleted 3y ago[deleted]
- robot_no_421 3y agoA linter or IDE can only "suggest" that you don't access null objects without a null check. You as the developer can choose to ignore the linter or IDE and write bad code anyway. Enforcing behavior via the typing system prevents bad code from even compiling and running in the first place. When you stop thinking of Optional<T> as a inconvenient wrapper clumsily wrapping a T and starting thinking of it as a first class datatype with its own members and methods, then it becomes a lot more clear to reason about the logic.
- mgaunard 3y agoThe C++ standard standardizes existing practice; it's not a place for innovation.
- mmoll 3y agoHuh? Who says so?
- jeroenhd 3y agoThe people writing the C++ standard seem to disagree.
- mgaunard 3y agoI have been part of the C++ standards committee for 13 years.
- jeroenhd 3y agoYour comment has led me down a rabbit hole regarding the C++ standards commission and corrected various misconceptions I've held for a while. You're right and I've made a fool of myself. My apologies.
- nurettin 3y agoYou really did not. Common practice and innovation are the same thing. Look at lambdas. Then polymorphic lambdas. Then async. Then modules. Innovation is obviously getting in. Parent commenter was being a pedant. Doesn't matter if he's stroustrup himself.