Description

Enchufa2

opened on Mar 24, 2025

Issue body actions

• Remove paths that rely on older standards.
• Include >= C++11 paths unconditionally.
• Assess TODO in inst/include/Rcpp/sugar/functions/sapply.h:42
• Then, RCPP_HAS_LONG_LONG_TYPES is defined unconditionally, remove checks.

Activity

1. Enchufa2

   added a parent issue on Mar 24, 2025

   • C++11 as minimum supported standard #1365
2. Enchufa2 commented on Mar 24, 2025

   

   Enchufa2

   on Mar 24, 2025

   MemberAuthor

   More actions

   What to do with

   Rcpp/inst/include/Rcpp/sugar/functions/sapply.h

   Lines 33 to 45 in 30edbf5

   	#if __cplusplus >= 201103L
   	#if __cplusplus < 201703L
   	// deprecated by C++17, removed by C++2020, see https://en.cppreference.com/w/cpp/types/result_of
   	typedef typename ::std::result_of<Function(typename SugarExpression::stored_type)>::type type;
   	#else
   	// since C++17, see https://en.cppreference.com/w/cpp/types/result_of
   	typedef typename ::std::invoke_result<Function, typename SugarExpression::stored_type>::type type;
   	#endif
   	#else
   	// TODO this else branch can likely go
   	typedef typename ::Rcpp::traits::result_of<Function>::type type;
   	#endif
   	};

   remains. We could remove the second branch as part of #1371, but I think that it would probably be better to remove the first branch, because I don't see how this is needed just here, and then a future improvement could be to reimplement ::Rcpp::traits::result_of using std stuff. It seems it is needed for lambdas, see #213. Then mapply and other functions won't work with lambdas either. So probably a separate issue dedicated to reimplementing result_of is indeed required.
3. eddelbuettel commented on Mar 24, 2025

   

   eddelbuettel

   on Mar 24, 2025

   Member

   More actions

   I think this #else is harmless and opted to keep it. If we decide to remove it I think we can/should also look into removing it definition -- ie ::Rcpp::traits::result_of<Function>::type.

   Reacted by Iñaki Ucar
4. Enchufa2 commented on Mar 24, 2025

   

   Enchufa2

   on Mar 24, 2025

   MemberAuthor

   More actions

   I pushed a branch feature/result_of_function that rewrites result_of to generalize the fix proposed for sapply, so that also lapply, mapply and outer can work with lambdas. What do you think?
5. eddelbuettel commented on Mar 24, 2025

   

   eddelbuettel

   on Mar 24, 2025

   Member

   More actions

   That sounds like a good way forward.
6. Enchufa2 commented on Mar 24, 2025

   

   Enchufa2

   on Mar 24, 2025

   MemberAuthor

   More actions

   Ok, then I'll rebase it when the current PR is merged, add more tests with lambdas, etc., and open a new PR for this.
7. eddelbuettel commented on Mar 24, 2025

   

   eddelbuettel

   on Mar 24, 2025

   Member

   More actions

   That sounds even better!
8. eddelbuettel

   closed this as completedin #1371on Mar 26, 2025

Issue actions