Type seperation & code bloat: dispatch vs compile type.

[ma.laf...@gmail.com]

It would be very nice to be able to seperate the dispatch function signature from the compiled type, for example:

#myfunction(x::DispatchType::CompileType) = ...
f(x::Real::Float64) = x^50

Which would basically translate to the following:

f(x::Float64) = x^50 #Main function
f(x::Real) = f(convert(Float64, x)) #Dispatch wrapper

Why?

1. Using concrete types reduces the number of possible "run paths" (**see below) for a given algorihm (reduces required # of tests to guarantee correctness).
2. Potentially reduces code bloat from compiling many specializations (vs only making the dispatch signature generic).
3. Less code bloat (potentially) = fewer cache misses + more efficiency.
4. Less verbose than manual implementation of (function + dispatch wrapper).
   

** The following is an example of a having unexpected "run paths":

function runalgorithm(x::Real)
    ...
    y50 = x^50 #Oops... Int(5)^50 = -6776596920136667815
    ...
    y50_again = x^50.0 #Computed correctly: 8.881784197001253e34
end

A string example

The proposed mechanism would also be good with another source of annoyance with file system strings:

You would think specifying file paths with `UTF8String` would be ideal for your function signatures:

typealias FileSystemString UTF8String

function dosomething(path::FileSystemString)
    ...
end

...but then users can not make direct calls with `ASCIIString`s:

#Will not work - not UTF8String:
dosomething("/home/user/myfile.txt")

So instead of going through the trouble of creating a generic dispatch wrapper function, I usually just end up making an overly generic implementation (succeptible to code bloat):

#Julia will create specializations for each concrete subtype:
function dosomething(path::AbstractString)
    ...
end

[Yichao Yu]

Yes
https://github.com/JuliaLang/julia/pull/15818#issuecomment-207922230
(The PR doesn't do that yet).

>

[ma.laf...@gmail.com]

Excellent.  Thanks for the heads up!