r.e. "impl's" on a type outside its original library crate .. i understand this is to preclude inter-crate clashes, if 2 library writers attempt to over-ride the same function.
i might be barking up the wrong tree here- rust has obviously been designed with the benefit of a lot of experience behind it. but... Would it be feasible to relax this error to a warning - or perhaps enable this behaviour with compiler options; one compromise might be to only make it an error when compiling a library**. potential use cases:- [1] When writing code that is never going to be put into a library, you'd be able to extend existing types with greater ease (less traits to make.. naming is hard, the fewer things you have to name the better). People writing smaller programs might make better use of existing types - especially while they're evolving.. and what doesn't evolve.. Any difference between usability of libary types and your own provides an incentive for NIH. a current example is the iterators which need the ".iter()" on the collection.. i've been tempeted to make workarounds to that. Open-world is a big draw to rust, it's over half the reason for my interest in this language... looking for a solution to the way headers & classes interact badly in C++. [2] Greater symetry between your own code where you may not have settled on libary/module divisons .. lets say you seperate part of a program out after it moves beyond a certain size, you'd have to start introducing extra traits... its just one more refactoring barrier. [3] I just thought about this for trying to write anIDE plugin.. .. currently you must compile an entire crate when something changes, which is very slow. But what if an IDE tool could divide the crate up into 1 crate per sourcefile, perhaps automatically generating an alternate 'main.rs' to pull these together. this is much like scenario [2]... this would involve having the same code compiling as either a multitude of crates, or being pulled together as one crate. in particular node ID's are enumerated for the entire crate, demanding a 'rebuild'. But I dont think you'd routinely/manually want to divide things up into one crate per sourcefile. personally i think i would prefer the restriction not to exist at all, i wouldn't mind the potential for libary link errors appearing; I read the opinion that it doesn't matter because you can submit changes to the original library code being opensource, but i think its *much* more feasible for members of the rust community to request changes or splits in eachother libraries versus submitting changes to the *standard* libaries, which, being used by more people are going to have greater momentum ,more disagreement, longer time to agree on the most widely accepted methods ... an individual library writer need merely be mindful of this hazrd. Doesn't matter if something is opensource .. it can be hard to change - its a point of disagreement and individuals might not considerevery other use case. In C++ I hear some people objecting to extention methods for the same reason, but this objection sounds unfounded to me because you can just make overloaded functions anyway already, and i've never ran into those being a problem. its just nicer to have the same a.foo(b) calling syntax available for everything .. is it possible for the module system to assist disambiguating if clashes do occur? there's always some use directives around.. could those prioritize the use of one supplied method over another. I know Go has a similar open world idea .. and a similar issue, no extending outside a package, just within sources of the same package, and there you have to make a new type to extend.. which is probably worse than making a new trait IMO. So perhaps rust is already the best balance here, i dont know. I do like the fact that in go methods aren't actually part of anything when defined, even less pre-planning going on, and their interfaces just gather them after they're written, but i prefer the inter-module behaviour of traits over what go does. ** .. you might say thats' inconsistent, different rules where the same source compiles, but you already have that by the fact this issue exists at all.
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev