Now, they should be correctly importing for the functions publicly
imported by std.string so that if those public imports are ever removed,
they won't break.
* adds the new API used for hashes/digests
* adds new crc & md modules using this API
* deprecate std.md5 & crc32
* update std.stream to use new hash API
This reverts commit d6c2ef0fb6.
These changes are valuable, but after further discussion, we've decided
to review how std.hash looks in general and redesign it, so getting
people to switch from crc32 to std.hash.crc32 will only mean that
they'll have to change their code _again_ once we've sorted out the
std.hash redesign, and we don't want that. So, I'm reverting these
changes for now, and they can become part of the std.hash redesign.
* remove `useWfuncs` using
* remove std.__file using
* remove __file.d
* remove variables which have become unnecessary
* remove std.windows.charset import and alias in file.d
This enables the test suite to build with the -property switch enabled.
std.cpuid: vendor()/processor() have not been converted to properties in accordance to core.cpuid.
std.xml: Element.text() cannot be a property due to the optional parameter.
isWhite, isLower, isUpper, toLower, and toUpper now have Ascii in their
name, which matches what std.unit does with its versions of those
functions. Hopefully, it should also reduce bugs due to using the wrong
function between the ASCII and unicode versions by making the difference
more obvious.
There was no consenus in the newsgroup about what to do about renaming
toStringz to be properly camelcased. It was pretty much divided between
renaming it to toCString and leaving it exactly as-is. No one wanted it
to be toStringZ. So, given the lack of consensus, I'm just going to
leave it as toStringz.
* Changed some declarations from explicit to auto.
* Changed "mkdir --parents" in Makefile to "mkdir -p" since OSX doesn't support the long version.
* REMAINING ISSUE: The "ln -sf" for installing the libraries at the end will fail if the DMD installation point is not owned by the user performing the build. A "sudo ln..." fixes this, but it still may not be ideal to have a system-level link to a user-level file. This should probably simply be copied instead. Also, this copy should perhaps be done manually or in an "install" step, since a user may want to build Phobos and test it out without affecting other users.
