Mmhmm, and yet nowhere in my question did I mention performance, although it needs to be consider, that wasn't what I was probing for. I was seeing if it was worth my time producing a prototype and it turns out given the objections to the feature itself that it isn't.
On 16 Nov 2016 9:40 am, "Joe Watkins" <pthre...@pthreads.org> wrote: > Morning, > > You started with an assumption, and ended by asserting that your > assumption was true. > > An implementation of overloading that somehow circumvents the obvious > performance impact, and compatibility problems is not easily conceivable, > at all. > > Cheers > Joe > > On Tue, Nov 15, 2016 at 4:13 PM, Dominic Grostate < > codekest...@googlemail.com> wrote: > >> I think this may have been discussed before, but I was largely dismissed >> because no one though it would be possible to implement. >> >> However assuming it is possible, what is the general feeling towards >> function overloading, as seen in C# and Java? >> >> To me, it saves me coming up with convoluted names for tackle various >> parameter combinations, even though the function/methods themselves all do >> the same thing, as well as saving having to omit type hinting in order to >> manually type check within the function. >> >> The previous RFC on union types attempted to fulfill a similar operation, >> but it failed to go through, but given the support it never the less had, >> I'm hoping that overloading will be more acceptable. >> >> To give an idea of how I'd implement it, I'd first try by hashing the >> function name with the type hints, plus the number of arguments, with >> variadics and references also taken into account on top of handling of >> dynamic arguments. >> >> The exact method is open to implementation, but it is possible to create >> an >> order priority and conflict resolution to enable overloading, while >> hopefully maintaining backwards compatibility with all existing >> core/ext/user functions. >> >> Please give your thoughts, thanks, >> Dominic >> > >
