Make machine types different from int/uint, etc.

[brson]

Right now i64 unifies with int on 64-bit platforms, etc, and it's a source of errors like in d65df5d. I believe they should be different types.

[nikomatsakis]

+1

[graydon]

Agreed. So long as you can cast I think this should be ok.

[nikomatsakis]

we probably want to address the reason that this change was introduced in the first place, which if I recall had something to do with sharing code in the various float modules? "boggle" on IRC was working on it, I think?

[brson]

I think this will force the float modules to use a bunch of wrapper functions.

[boggle]

Yes, if I remember correctly the plan was to add a pragma to enable this behavior per module or function. I really would not want the float module to have to use wrapper functions for performance reasons; an alternative could be to support typecasting of function prototypes on export as a means of explicit unification.

[brson]

I think there is a way to avoid duplicating code here by using a single 'template' module with multiple types.

We would arrange the modules like:

// Use one template module to specify in a single file the implementation
// of functions for multiple types

mod mystd {

    // The template on type T is specified in float-template.rs
    #[path = "float-template"]
    mod float {
        // The type of the float
        import inst::T;

        // Define T as float
        #[path = "inst_float.rs"]
        mod inst;
    }

    // Use the same template
    #[path = "float-template"]
    mod f64 {

        import inst::T;

        // Define T as f64
        #[path = "inst_f64.rs"]
        mod inst;
    }

    #[path = "float-template"]
    mod f32 {
        import inst::T;

        #[path = "inst_f32.rs"]
        mod inst;
    }

}

It gets more complicated when you take into account that, in the real library, you would have two implementations of the template, one for 32-bit types and one for 64-bit.

There is a full test case in 611061b

[boggle]

Interesting idea, this could work, I did not know about #[path]. Available annotations like that need more documentation. I have two questions though: Can I use #[cfg] on mod float in this scenario to switch depending on the architecture? Does that work with native modules (f32, f64 right now directly rename lib math calls to proper rust calls via #[link_name])?

While I find this ok for core::float, in general I wonder wether this is not a bit too much overhead for someone who just wants to write library bindings in a similar situation and needs float <--> fXY equality.

[nikomatsakis]

Woah, @brson, I do not quite understand what's going on there, but it looks cool. What does #[path] do?

[nikomatsakis]

Brian's stuff got me to thinking. To be honest, I don't really understand what the problem with the floating point modules was precisely (I guess I have to go look at core::float?), but I am sure we can solve it through some combination of ifaces/impls, macros, and (eventuaIly) traits. The annoying part is that only the first one exists today, or so we thought: but Brian's module trick essentially gives us C's #include, so in fact we do have a kind of macro today (and macros let us build up simple traits, too).

[boggle]

Look at core::float. The gist is this: Each function in C lib math exists in one version per datatype (f32, f64, ...). I use native modules that in a first step rename these to identical function names. After this point all that is wanted is to export the f64 ones as f64, the f32 ones as f32, and whichever happens to be identical to float as float. Any suggestions welcome but please don't introduce unnecessary wrappers etc, I'd really like to keep this fast. I see traits here more as a means of building a number tower later on (maybe a "native" impl that directly links agains a C lib could help).

[brson]

@boggle, yes, the float mod would have to have two versions, one with #[cfg(target_arch = "x86_64")] that uses f64-template and another for x86.

@nikomatsakis I think this technique does things that traits and impls can't. I arrived at it after trying to think of a way to use impls without a bunch of wrappers.

@boggle Wrappers should not be a performance concern here since we can mark them with #[inline(always)]. I think the issue is mostly one of code duplication.

[brson]

I think this technique should allow anything that can be put into a module to be parametrized over... anything else that can be put into a module?

[brson]

Oh, #[path] just specifies the name of the file/directory to use as the implementation of a module.