On Monday, 4 July 2022 at 05:35:20 UTC, rikki cattermole wrote:
On 04/07/2022 5:30 PM, Andrej Mitrovic wrote:
Aren't these the polar opposites of each other? The GC is one
of D's strengths, yet we should avoid it as much as possible
in the standard library.
Not necessarily.
It could and
On 04/07/2022 5:30 PM, Andrej Mitrovic wrote:
Aren't these the polar opposites of each other? The GC is one of D's
strengths, yet we should avoid it as much as possible in the standard
library.
Not necessarily.
It could and should most likely mean that it won't do any heap allocations.
On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote:
You can find the final draft of the high-level goals for the D
programming language at the following link:
https://github.com/dlang/vision-document
Under 'Memory safety':
Allow the continued use of garbage collection as the default
We have a perfectly good Unicode handling library already.
(Okay, little out of date and doesn't handle Turkic stuff, but fixable).
The standard one is called ICU.
Anyway, we are straying from my original point, that limiting ourselves
to the string alias and not supporting wstring or dstring
On Sunday, 3 July 2022 at 20:28:18 UTC, rikki cattermole wrote:
We only support UTF-16/UTF-32 for the target endian.
Text input comes from many sources, stdin, files and say the
windowing system are three common sources that do not make any
such guarantees.
Well, then the application author
On 04/07/2022 8:16 AM, Ola Fosheim Grøstad wrote:
On Sunday, 3 July 2022 at 19:32:56 UTC, rikki cattermole wrote:
It is required for string equivalent comparisons (which is what you
should be doing in a LOT more cases! Anything user provided when
compared should be normalized first.
Well, I
On Sunday, 3 July 2022 at 19:32:56 UTC, rikki cattermole wrote:
It is required for string equivalent comparisons (which is what
you should be doing in a LOT more cases! Anything user provided
when compared should be normalized first.
Well, I think it is reasonable for a protocol to require
On Sunday, 3 July 2022 at 19:32:56 UTC, rikki cattermole wrote:
I have just finished implementing string normalization which is
based around UTF-32.
There's a difference between utf-32 and unicode code points.
It is required for string equivalent comparisons (which is what
you should be
On 04/07/2022 7:18 AM, Ola Fosheim Grøstad wrote:
I hardly ever use anything outside UTF-8, and if I do then I use a well
tested unicode library as it has to be correct and up to date to be
useful. The utility of going beyond UTF-8 seems to be limited:
On Sunday, 3 July 2022 at 18:33:29 UTC, rikki cattermole wrote:
On 04/07/2022 6:10 AM, Ola Fosheim Grøstad wrote:
People who are willing to use 4 bytes per code point are
probably using third party C-libraries that have their own
representation, so you have to convert anyway?
If you use
On Sunday, 3 July 2022 at 18:33:29 UTC, rikki cattermole wrote:
Its just an unnecessary goal, when most of the string
algorithms we have probably don't care about the encoding and
those that do probably will be using dstrings.
To the contrary, I find this goal coherant with the end of
On 04/07/2022 6:10 AM, Ola Fosheim Grøstad wrote:
People who are willing to use 4 bytes per code point are probably using
third party C-libraries that have their own representation, so you have
to convert anyway?
If you use Unicode and follow their recommendations, you are going to be
On Sunday, 3 July 2022 at 17:27:43 UTC, rikki cattermole wrote:
That's going to bite us big time when it comes to Unicode
handling which wants to work with dstring's.
You can just use ints… It is better to do something commonly used
well, than have features that not enough people use to get
> Stronger integration with other languages
One of the things I judge D's compilers by is how well they can build a
shared library.
This is crucial for a lot of different applications of D and can be an
complete stopper in using D if it doesn't "just work".
To be blunt this is
On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote:
Feedback is welcome.
Metaprogramming
This section is... light on details and does little to clear up
if you share my goals.
My current take on this is that I believe something with c
feature ser + templates are the future, their
On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote:
Feedback is welcome.
Had a hope to see the "complete started but abandoned features"
point.
On Sunday, 3 July 2022 at 11:39:45 UTC, Mike Parker wrote:
Language evolution doesn't really mean much until we get all of
this sorted.
Good point.
That's right. But Walter wants to minimize its use in Phobos
v2, and there's a strong desire to have a pay-as-you-go
DRuntime. I'm not the
On Sunday, 3 July 2022 at 11:13:42 UTC, Ola Fosheim Grøstad wrote:
On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote:
Feedback is welcome.
Thank you for putting this in clear terms. I miss an
overarching «primary use scenarios» to guide further language
evolution. How do you know if
On 03.07.22 10:46, Mike Parker wrote:
You can find the final draft of the high-level goals for the D
programming language at the following link:
https://github.com/dlang/vision-document
Quoting from the "Memory safety" section:
The language maintainers do not see memory safety as a fad,
On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote:
Feedback is welcome.
Thank you for putting this in clear terms. I miss an overarching
«primary use scenarios» to guide further language evolution. How
do you know if new language features are good or bad if you have
no scenarios to
You can find the final draft of the high-level goals for the D
programming language at the following link:
https://github.com/dlang/vision-document
I'll fill out the remaining sections as time allows over the
coming weeks. Once it's complete, I'll make sure it's linked in
the Community
21 matches
Mail list logo
