Closed JOOpdenhoevel closed 4 years ago
i'm ok to remove the experimental target features as long we mention support level for target. This simplify conditional compilation and explanation in documentation. For the tiers:
@Janonard what's up ?
for the second point of my previous post, another solution is to put such target in tier2, since it concern only some windows targets where bindings don't have relevant difference.
@Janonard what's up ?
I'm sorry, I was busy with work and learning for an unexpected exam.
i'm ok to remove the experimental target features as long we mention support level for target. This simplify conditional compilation and explanation in documentation.
Do you mean that you want to mention the support levels in the docs (what we are doing right now) or do you want to mention the support levels in something like compiler warnings? I would object to the later since rustup
doesn't give you a warning when you install a Tier 2 or Tier 3 target too.
i don't see the interest to use rust tiers as condition for "support level".
I thought this would give the user a better idea on what to expect from a target.
it does'nt mention targets that build as "side effect". For example, we don't have generated binding for 'x86_64-pc-windows-gnu' but Rust-lv2 can be build for that target. Maybe having a tiers 3 for this kind of targets.
This is correct, but is this important? Again, the Tiers state the level of support for a target. If we didn't intend to add bindings for a target, then we're not supporting it and it shouldn't be listed. I think this fits quite nicely.
for maintenance, it's may usefull to mention the used binding file for tiers 1 and 2, because some targets will share same binding file.
I absolutely agree with you! I will add that!
This basically mimics the platform support scheme of rustc and hopefully makes clear what to expect on which targets. I've also removed the experimental targets feature since rustc doesn't have such a guard too, which would break the parallelism in the scheme.