On Friday, 12 April 2013 at 06:25:10 UTC, Manu wrote:
Sorry to derail the topic, but I'd just like to raise a major
gripe I've
had with introducing anything into phobos recently.
I see this pattern where something is designed, discussed, and
then voted
into phobos. At this time the design looks good on paper, but
there is very
little practical experience using the library.
The problem then is, once accepted, people start using it, and
at some
point some issues are found, or ideas for improvement are made
based on
user experience, but the module can no longer be touched due to
the general
phobia of making breaking changes...
Can I suggest that ALL new modules should be added to exp.
rather than
std.? Here they will stay for at least 1 year, and while they
live in exp,
it is understood that they are still in an experimental
introductory phase.
Users who choose to use modules in exp are accepting that the
API may
receive changes, and consequently, accepting the responsibility
to update
their code (and not complain about it breaking their program),
should the
library be amended in its introductory phase.
At some time later when the module has been used in a decent
amount of
software, and the API has stabilised, it can then be moved to
std. This
move is obviously a breaking change its self, but anyone who
has agrees to
import exp modules has already accepted the responsibility to
update their
code as such.
Thoughts?
On 12 April 2013 16:12, Nick Sabalausky
<[email protected]
wrote:
On Fri, 12 Apr 2013 06:46:51 +0200
"Jesse Phillips" <[email protected]> wrote:
> It is that time, If you would like to see the proposed
> std.process include into Phobos please vote yes. If one
> condition
> must be met specify under what condition, otherwise vote no.
>
Yes
Fully agree
