Other languages have had experience with adding features along these lines and some have then become harder to use for some part of the user community.
Languages like R and Python started off deliberately in various directions that include being interpreted on the fly rather than compiled once and run many times. They were designed to be in a sense polymorphic so that a function can be called with almost any kinds of arguments and be able to return almost any result. It was supposed to be easy to quickly write a function, have it work rapidly on some kind of arguments, then go and amend it to make sure it works for any other reasonable arguments. Optionally, it could then be enhanced internally to do all kinds of checking to make sure the arguments make sense and to do something proper when they don't. And, since R is dynamic then at run-time, you never know if somewhere along the line, an argument type passed along from other functions might be different than expected. A static checker can fail. In languages that allow strict typing, it often can take serious effort to specify that a complex combination of types is allowed. R also has a feature that can get in the way here as it allows, and often even encourages, delayed evaluation. Consider a fairly simplistic technique that might be used elsewhere. Allow the creation of functions that can be used like this: Result <- f( check(arg1, constraints, ...), check(arg2, constraints, ...)) Functions like "check" might use the arguments I labeled "constraints" to decide whether to simply return whatever "arg" was or treat it as an error, or even make a conversion of arg to return an expected value. In some languages, it might be as simple as converting an integer to the expected floating point value, or doing some unboxing. But would any design along these lines work? I mean do you want an argument evaluated before knowing if it will be used? Side-effects can happen and so on. And, if the function expects an unevaluated argument so it can decide when and how to activate it, you lose abilities like being able to have ggplot2 label an axis with the original text. As many languages converge in the sense of all being able to do some similar things, some users may simply look at some complex scheme they do not like, and shift to a more comfortable language. How much of what people are using R for, can somewhat migrate to a language like Python which does not have an object system cobbled together with S3 and S4 and others grafted on, and has modules like numpy and pandas that allow way to do things. I am not suggesting this makes sense, just that, after a whlle, each language can be designed to fit some things better and not try to do everything else. Obviously, many suggestions to this kind of enhancement would allow all existing programs to continue working and just enhance things for those who want to add optional phrasing to a command. But, sometimes, what you end up with is what happened to Python, where the new version is incompatible and eventually people who keep using the old version will lose support. And a very big question is the one about funding such an effort and what else could be done that gives programmers other things this might get in the way of. 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 "verify(..., more)" If you wanted efficiency, you could redefine verify() to do nothing, or just do a few tests. Any utilities that want to document what a functions parameters could look like, would look at such a line in the body of the function to document it. Obviously, you do need a proper way to make this function do things like force a return value or propagate error signals or write things to a log but such an approach could be less invasive than making major changes to the language and how it is parsed. These are just thoughts. Not a request. I do not currently have any major needs regarding R. -----Original Message----- From: R-devel <[email protected]> On Behalf Of Simon Urbanek Sent: Wednesday, November 26, 2025 7:04 PM To: ivo welch <[email protected]> Cc: [email protected]; Welch, Ivo <[email protected]> Subject: Re: [Rd] Declaring Types at Function Declaration The R5 syntax introduced over 15 years ago it was meant to be minimalistic (optional argument types) to have a start at experimenting, however there was little interest at the time. Then I remember at one of the useR!’s I think someone from Jan Vitek’s group was presenting on a very complex annotation system that allowed not only type checking, but also definition of constraints etc. (unfortunately I can’t remember the names and so didn't find the paper). At that time I was thinking that it’s cool, but this will never happen, because once you start exploring all the possible use-cases the scope grows exponentially and it will become impossible to agree on any common ground: the classic perfect being the enemy of the good. So I suspect that is the main problem: it is not a clear feature that has a clear path forward - it is just an ill-defined idea (what is the purpose? about arguments? about other expressions? constraints? evaluated constraints? return values? what will be done with it?). Add to that the obvious: it would be possibly a big change to the language, so it really needs to be considered carefully as there will be no going back, since R prides itself on very good backward compatibility which makes it so useful in practice. Also anything complex will have security and performance implications. I have not seen any serious proposals so far. There have been various experimentation in a package space, but those are often opinionated with varying levels of thought put into it. Personally, I think the syntax is important so I would like to make sure possible syntax changes are considered so we’re not just creating an awkward syntax because it is easier in package space, but not intuitive to use. So just like with any improvement (c.f. the ifelse discussion), if there is actual interest, then people should start discussing the aspects, starting with the key ones such as purpose and requirements. I don't think this topic really has been even defined so I wouldn’t run creating packages just yet, especially since I think this is more about design than implementation. No one has done that work just yet. Cheers, Simon > On 27 Nov 2025, at 05:59, ivo welch <[email protected]> wrote: > > I am more interested why something like this has not made its way into R core > as a first step to type checking *for everyone*. (I could imagine that an > option would turn on and off some automatic stopifnot like checking given a > standardized annotation form [type, dim].) > > is it because there is not much wider interest and desirability (so even a > basic working implementation would not be pulled into R by the powers that > are in charge), or is it because the work is too difficult and no one had > time to work on it? > > > On Wed, Nov 26, 2025 at 8:50 AM Hadley Wickham <[email protected]> wrote: > >> You might be interested in Jim Hester’s old experiment that used ? - >> https://github.com/jimhester/types >> >> Hadley >> >> On Wednesday, September 17, 2025, 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 >>> >> >> >> -- >> http://hadley.nz >> > > [[alternative HTML version deleted]] > > ______________________________________________ > [email protected] mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
