earthquake changes of std.regexp to come

[Yigal Chripun]

Andrei Alexandrescu wrote:
> dsimcha wrote:
>> == Quote from dsimcha (dsimcha at yahoo.com)'s article
>>> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s
>>> article
>>>> I'm quite unhappy with the API of std.regexp. It's a chaotic design
>>>> that
>>>> provides a hodgepodge of functionality and tries to use as many
>>>> synonyms
>>>> of "to find" in the dictionary (e.g. search, match). I could swear
>>>> Walter never really cared for using regexps, and that is felt
>>>> throughout
>>>> the design: it fills the bullet point but it's asinine to use.
>>>> Besides std.regexp only works with (narrow) strings and we want it to
>>>> work on streams of all widths and structures. One pet complaint I have
>>>> is that std.regexp puts a class around it all as if everybody's
>>>> favorite
>>>> pastime would be to inherit Regexp and override some random function
>>>> in it.
>>>> In the upcoming releases of D 2.0 there will be rather dramatic
>>>> breaking
>>>> changes of phobos. I just wanted to ask whether y'all could stomach yet
>>>> another rewritten API or you'd rather use std.regexp as it is for the
>>>> time being.
>>>> Andrei
>>> As I've said before, anyone who can't stomach breaking changes w/o
>>> complaining has
>>> no business using D2 at this point. I'd rather deal with the
>>> aggravation of stuff
>>> breaking in the sort run to have a nice language and libraries to go
>>> with it in
>>> the long run.
>>> This whole concept of ranges as you've created them seems to have
>>> achieved the the
>>> holy grail of both making simple things simple and complex things
>>> possible, where
>>> "complex things" includes needing code to be efficient, so I can see
>>> your reason
>>> for wanting to redo all kinds of stuff in them. This compares
>>> favorably to C++
>>> STL iterators, which are very flexible and efficient but a huge PITA
>>> to use for
>>> simple things because the syntax is so low-level and ugly, and to the
>>> D1/early D2
>>> way, which gives beautiful, simple notation for the more common cases
>>> (basic
>>> dynamic arrays), at the expense of flexiblity when doing more
>>> complicated things
>>> like streams, chaining, strides, etc.
>>
>> BTW, can you elaborate on how arrays, both builtin and any library
>> versions, will
>> work when everything is finalized?
>
> Well finalizations hinges not only on me but on Walter (bugfixes and a
> couple of new features) and on all of you with the continuous stream of
> great suggestions and ideas. Again, without being able to experiment
> much I don't have a clear idea on how arrays/containers should at best
> look like. The interesting challenge is accommodating good, precise
> semantics with the freedom given by garbage collection. Here are some
> highlights:
>
> * Today's T[] will be firmly an incarnation of the random-access range
> concept, to the extent that all code expecting a random-access range can
> always be passed a T[] without any impedance adaptation.
>
> * $ will be generalized to mean "end of range" even for infinite ranges.
>
> * We don't have a solution to address the perils of extending a slice by
> using ~=. We're considering adding the type T[new], but I'm not sure we
> should take the hit of a new built-in type constructor, particularly
> when it's implementable as a library.
>
> * Fixed-size arrays will in all likelihood be value types. We couldn't
> find any other semantics that works.
>
> * Containers will have value semantics.
>
> * "Resources come and go; memory is forever" is the likely default in D
> resource management. This means that destroying e.g. an array of File
> objects will close the underlying files, but will not deallocate the
> memory allocated for them. In essence, destroying values means calling
> the destructor but not delete-ing them (unless of course they're on the
> stack). This approach has a number of disadvantages, but plenty of
> advantages that compensate them in most applications.
>
> * std.matrix will define memory layouts for a variety of popular
> libraries and also the common means to iterate said layouts.
>
> * For those who want containers with reference semantics, they can use
> the type Class!(T) for any value type T. That includes built-in value
> types (int, float...) and whichever value containers we define. It's
> unclear to me whether this is enough to satisfy those in need for
> complex container hierarchies.
>
>
> Andrei

Another question regarding the container design - have you considered 
mutable containers vs. functional style imutable containers? does it 
make sense to provide both options?