thank you, everyone. it seems to me from the outside that the key aspect that is missing is the core R team having an interest and taking the lead on something...anything.
I am not an R developer, just a medium-sophisticated occasional R end user in the trenches, and not a very good one at that. so, in my trench, I would love anything that makes code easier to read and bugs earlier and easier to find. Jan's proposal seems great. if integrated into the language, perhaps with an option to either ignore the checks or issue warnings when functions are not annotated, they would make my code better and my life easier. it would be even better if R in general migrated to it, so everyone understood that this is the better way to write code. sort of like conventions for indentations. Josiah has amazing discipline to put all the checks into his functions that I wish I had. alas, this greatly reduces readability of the function in my mind. again, it seems to me that it is the R core team that needs to decide...and I think they decided it isn't worth it. this is why they are paid the not-so-big bucks. I view how they decided as a pity, but it isn't me but the people who do the work that should decide. -- Ivo Welch ([email protected]) On Thu, Nov 27, 2025 at 9:42 AM Josiah Parry <[email protected]> wrote: > "Are there suggestions on the table for something like a group of >> functions that can be optionally > > placed at the beginning of a function that do all the verifications needed >> and that can also provide > > some other things. What if the first line of your function looked like" > > > ^ Yes, this is what the {rlang} standalone checks do. See the source: > https://github.com/r-lib/rlang/blob/main/R/standalone-types-check.R > > I wrote about how I use them in the package {arcgisgeocode} > https://josiahparry.com/posts/2024-06-30-type-safety/ > > This is a staple in every package I develop. It stops a lot of errors from > occurring but it's definitely not as easy as `arg: integer()`. > > Example usage: > https://github.com/R-ArcGIS/arcgisgeocode/blob/3a7877641ca2f3a761ef0ec3a7486820ab94c9cc/R/core-find-candidates.R#L104-L141 > > "Of course R does have comments" > > > ^ Comments aren't visible to users of packages. Having type checking on > inputs is a huge QOL improvement that can reduce the number of > accidental bugs. {S7} helps get there but I find myself using the same > rlang checks even in S7. > > > On Thu, Nov 27, 2025 at 9:09 AM Gabor Grothendieck < > [email protected]> wrote: > >> Of course R does have comments: >> >> f <- function( a, # character >> b, # data.frame >> c # logical >> ) { >> ... >> } >> >> On Wed, Sep 17, 2025 at 1:26 PM IVO I WELCH <[email protected]> wrote: >> > >> > >> > Suggestion for Syntax Sugar: >> > >> > Would it make sense to permit a simple way to allow a coder to document >> the function argument type? >> > >> > f <- function( a:chr, b:data.frame, c:logi ) { … } >> > >> > presumably, what comes behind the ‘:’ should match what ‘str’ returns. >> > >> > however, this need not be checked (except perhaps when a particular >> option is set). catching errors as soon as possible makes code easier to >> debug and error messages clearer. >> > >> > regards, >> > >> > /iaw >> > >> > ______________________________________________ >> > [email protected] mailing list >> > https://stat.ethz.ch/mailman/listinfo/r-devel >> >> >> >> -- >> Statistics & Software Consulting >> GKX Group, GKX Associates Inc. >> tel: 1-877-GKX-GROUP >> email: ggrothendieck at gmail.com >> >> ______________________________________________ >> [email protected] mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > [[alternative HTML version deleted]] ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
