On Saturday, 9 July 2022 at 23:40:21 UTC, monkyyy wrote:
Its not curated
Well, limit yourself to usage of `std` or `phobos` or whatever
official implementation is called - and voila, it's curated.
It changes the compiler options
So? Most of the people prefer to have build tool managing
On Monday, 4 July 2022 at 08:34:14 UTC, Mike Parker wrote:
Walter and Atila have both talked about rethinking exceptions.
Atila brought it up in his DConf Online 2021 talk here:
https://youtu.be/UqW42_8kn0s?t=1429
You can see Walter's comments about it in the subsequent Q & A
session here:
On Saturday, 9 July 2022 at 23:40:21 UTC, monkyyy wrote:
... and its randomly configured in js.
json or sdl, with well documented structure, not random js.
On Saturday, 9 July 2022 at 22:59:19 UTC, Vladimir Marchevsky
wrote:
On Sunday, 3 July 2022 at 17:09:46 UTC, monkyyy wrote:
Id suggest dropping std.experimental and get a std.community
sort of thing going.
Well, it's named dub :)
Its not curated. Its enforces a vision. It changes the
On Sunday, 3 July 2022 at 17:09:46 UTC, monkyyy wrote:
Id suggest dropping std.experimental and get a std.community
sort of thing going.
Well, it's named dub :)
Thanks for this.
As a casual D user who is coming from a Java background, I'm of
the opinion that we do indeed need to improve Phobos to either
(a) include lots of stuff in the std lib itself, or (b) guide
users to trusted, well-tested third-party libraries. I've tried
doing things with
Mike has our full support in his moderation policy and authority.
On Wednesday, 6 July 2022 at 21:30:44 UTC, Dukc wrote:
And I think there is still pretty much value in handling UTF-16
strings because that's what many other languages use. With the
current vision, Phobos V2 won't handle UTF16 in place. We'll
have to convert it to UTF8 before manipulation,
On Wednesday, 6 July 2022 at 15:43:25 UTC, ryuukk_ wrote:
On Wednesday, 6 July 2022 at 14:30:07 UTC, Paulo Pinto wrote:
On Tuesday, 5 July 2022 at 12:34:57 UTC, ryuukk_ wrote:
On Monday, 4 July 2022 at 05:30:10 UTC, Andrej Mitrovic wrote:
[...]
GC is one of D's strength because it is
On Sunday, 3 July 2022 at 20:16:35 UTC, 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
On Monday, 4 July 2022 at 08:34:14 UTC, Mike Parker wrote:
[snip]
I think that's a reasonable policy. The last thing any of us
want is to stifle debate or censor opinions, but we feel that
it's reasonable to ask people to participate in debates and
express their opinions without upsetting
On Wednesday, 6 July 2022 at 14:30:07 UTC, Paulo Pinto wrote:
On Tuesday, 5 July 2022 at 12:34:57 UTC, ryuukk_ wrote:
On Monday, 4 July 2022 at 05:30:10 UTC, Andrej Mitrovic wrote:
On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote:
You can find the final draft of the high-level goals
On Tuesday, 5 July 2022 at 12:34:57 UTC, ryuukk_ wrote:
On Monday, 4 July 2022 at 05:30:10 UTC, Andrej Mitrovic wrote:
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:
On Tuesday, 5 July 2022 at 11:49:20 UTC, ryuukk_ wrote:
I am sad that no word on the Allocator API, moving forward i
personally think APIs that use memory should be required to ask
for an Allocator and do their allocation using it, and only it
A default GCAllocator could be used if none
On Tuesday, 5 July 2022 at 12:34:57 UTC, ryuukk_ wrote:
GC is one of D's strength because it is optional, not making
core APIs bing-your-own-memory-allocation-strategy through nogc
or allocators, is making it no longer optional, which is no
longer a strength imo
You don't want GC when you do
On 05/07/2022 11:49 PM, ryuukk_ wrote:
Hopefully that includes proper built in Tagged Union, non OOP people
need that otherwise we are stuck in C's era of programming
C's era of programming also happens to coincide with ML which had tagged
unions ;)
The C family has never been very
On Monday, 4 July 2022 at 05:30:10 UTC, Andrej Mitrovic wrote:
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
Pattern matching
Hopefully that includes proper built in Tagged Union, non OOP
people need that otherwise we are stuck in C's era of programming
We can, and we should do better (import std.sumtype is
embarrassing when other languages have it built in without
template soup, i still refuse
On Monday, 4 July 2022 at 16:12:35 UTC, rikki cattermole wrote:
https://www.unicode.org/Public/14.0.0/ucd/NormalizationTest.txt
Argh, linking to large files...
My implementation passes this :3
It should be complete test cases.
Well, you also have to test for the cases that should not
On 04/07/2022 7:39 PM, Ola Fosheim Grøstad wrote:
Yes, that is a common one that is maintained, but maybe there are BOOST
licensed implementations too? One can do an exhaustive test for say
two-character normalization against ICU to see if they are compliant.
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
I also want to reiterate that this is a living document. We
will modify the goals as
On Monday, 4 July 2022 at 07:28:23 UTC, StarCanopy wrote:
On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote:
[...]
Given the desire to reduce GC usage in PhobosV2, would it be
fair to say this implies changing error handling schemes found
therein, i.e. avoiding exceptions as they are
On Monday, 4 July 2022 at 05:51:48 UTC, Andrej Mitrovic wrote:
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
On Sunday, 3 July 2022 at 21:06:40 UTC, rikki cattermole wrote:
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.
Yes, that is a common one that is maintained, but maybe there
On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote:
[...]
Firstly, thank you for composing this.
Given the desire to reduce GC usage in PhobosV2, would it be fair
to say this implies changing error handling schemes found
therein, i.e. avoiding exceptions as they are implemented now,
On Monday, 4 July 2022 at 06:01:09 UTC, Mike Parker wrote:
So what the `@nogc as much as possible` goal means is that it
should be a consideration for the implementation of Phobos v2
from the beginning. The design of the API should allow `@nogc`
client code to make use of it as much as
On Monday, 4 July 2022 at 05:30:10 UTC, Andrej Mitrovic wrote:
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
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
47 matches
Mail list logo
