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
