[Rd] Declaring Types at Function Declaration

[ivo welch]

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 (ivo.welch using ucla.edu)



On Thu, Nov 27, 2025 at 9:42 AM Josiah Parry <josiah.parry using gmail.com> 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 <
> ggrothendieck using gmail.com> 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 <iwelch using g.ucla.edu> 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
>> >
>> > ______________________________________________
>> > R-devel using r-project.org 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
>>
>> ______________________________________________
>> R-devel using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>

	[[alternative HTML version deleted]]