I'd put together one version of a gist of how this could work in the past, and Jeff's mentioned a similar draft idea he had in an early design document. In the end, however, I think this just ends up falling in the category of "features that just aren't actually desirable to have". It adds complexity to the compiler, true. More importantly though, it adds additional complexity to the user's concept of a function, and without sufficient benefit to justify itself. This feature is often useful in matlab for avoiding the expense of some extra computations (which are often very expensive in matlab in the first place), but it's also often abused to have a function do something different. Additionally, it makes composability much more difficult (since the function call starts to depend upon the syntax of the call), such that it can be harder to write fully generic code.
Julia code is already much more expressive than C, and requires explicit ccall / cfunction conversions to translate between the languages, so direct compatibility isn't actually much of a concern. On Fri, Mar 6, 2015 at 9:13 PM Kevin Squire <kevin.squ...@gmail.com> wrote: > On Fri, Mar 6, 2015 at 11:43 AM, J Luis <jmfl...@gmail.com> wrote: > >> Is there any fundamental reason why the nargout mechanism cannot (or is >> very hard) to implement? >> Because if not I really think it would be very very handy to have it. >> While we can workaround the nargin concept with the multiple dispatch, the >> same does help for the nargout. >> > > I'm not an expert on the innards of the Julia compiler, but I believe the > most important reason is that it interferes with type stability of a > function, which in turn interferes with the ability of the compiler to > generate optimized code. > > Additionally, functions can currently be used as callbacks from C and > Fortran code (and there's generally a desire to keep/enhance C > interactivity as much as possible). If we wanted functions to know the > number of output parameters, there would need to be a mechanism to provide > this information to the function at call time (e.g., the number of args > would perhaps need to be passed in as a hidden parameter). As there is no > mechanism to do this in C, we would either lose compatibility with C, or > need to provide a new kind of function, solely for this purpose. > > So while adding such functionality might add convenience (mostly for > people coming from Matlab), it 1) would produce slower, less optimized > code, and 2) would require adding a new kind of function to the language > and compiler (which is already pretty complicated). > > I think that would be a pretty hard sell to the primary developers. > > Cheers! > > Kevin >
