On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
The subject says it all.
If you care about memory safety, I recommending adding `safe:`
as the first line in all your project modules, and annotate
individual functions otherwise as necessary. For modules with C
declarations, do as
Am 29.05.20 um 06:53 schrieb Walter Bright:
> The subject says it all.
>
> If you care about memory safety, I recommending adding `safe:` as the
> first line in all your project modules, and annotate individual
> functions otherwise as necessary. For modules with C declarations, do as
> you think
On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
The subject says it all.
If you care about memory safety, I recommending adding `safe:`
as the first line in all your project modules, and annotate
individual functions otherwise as necessary. For modules with C
declarations, do as
On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
The subject says it all.
If you care about memory safety, I recommending adding `safe:`
as the first line in all your project modules, and annotate
individual functions otherwise as necessary. For modules with C
declarations, do as
The subject says it all.
If you care about memory safety, I recommending adding `safe:` as the first line
in all your project modules, and annotate individual functions otherwise as
necessary. For modules with C declarations, do as you think best.
For everyone else, carry on as before.
On Thursday, 28 May 2020 at 12:28:16 UTC, Sebastiaan Koppe wrote:
On Thursday, 28 May 2020 at 09:21:09 UTC, Jonathan M Davis
wrote:
He did unfortunately manage to convince Atila, so the DIP has
been accepted, but based on the discussions, I think that you
may be the only person I've seen say
On Thursday, 28 May 2020 at 17:45:26 UTC, Russel Winder wrote:
[snip]
This last is sad, for me. I like using test functions rather
than named unittest blocks.
I recall playing with them when it was originally announced and
thought they were quite nice, but I haven't used them since.
The
On Thu, 2020-05-28 at 15:35 +, Atila Neves via Digitalmars-d-announce
wrote:
> I decided to stop being like Google and finally tag version 1 of
> unit-threaded:
>
> https://code.dlang.org/packages/unit-threaded
>
> From now on I'm going to focus on compilation speed (no matter
> how ugly
Am Thu, 28 May 2020 12:28:16 + schrieb Sebastiaan Koppe:
> On Thursday, 28 May 2020 at 09:21:09 UTC, Jonathan M Davis wrote:
>> He did unfortunately manage to convince Atila, so the DIP has been
>> accepted, but based on the discussions, I think that you may be the
>> only person I've seen
Am Thu, 28 May 2020 10:50:44 +0200 schrieb Daniel Kozak:
> On Thu, May 28, 2020 at 4:56 AM Jonathan M Davis via
> Digitalmars-d-announce wrote:
>>
>> As far as I can tell, Walter understands the issues but fundamentally
>> disagrees with pretty much everyone else on the issue.
>
> I do not
I decided to stop being like Google and finally tag version 1 of
unit-threaded:
https://code.dlang.org/packages/unit-threaded
From now on I'm going to focus on compilation speed (no matter
how ugly that might make the implementation), and also dropping
support in v2.x.x for anything other
On Thursday, 28 May 2020 at 02:47:01 UTC, Jonathan M Davis wrote:
Walter has acknowledged the problem and seems to think that
because it's the programmer's responsibility to deal with
extern(C) functions correctly (since it's not possible for the
compiler to do it), it's up to the programmer
On Thursday, 28 May 2020 at 09:21:09 UTC, Jonathan M Davis wrote:
He did unfortunately manage to convince Atila, so the DIP has
been accepted, but based on the discussions, I think that you
may be the only person I've seen say anything positive about
the DIP treating extern(C) functions as
On Thu, May 28, 2020 at 03:21:09AM -0600, Jonathan M Davis via
Digitalmars-d-announce wrote:
[...]
> With the DIP in its current state, @safe becomes a lie. The compiler
> no longer guarantees that @safe code is memory safe so long as it
> doesn't call any @trusted code where the programmer
On 28.05.20 10:50, Daniel Kozak wrote:
He seems to think
that weakening @safe is worth doing, because it will ultimately mean that
more code will be treated as @safe and mechnically checked by the compiler,
And I believe he is right.
No, it's a false dichotomy. Weakening @safe to allow more
On Thursday, May 28, 2020 2:50:44 AM MDT Daniel Kozak via Digitalmars-d-
announce wrote:
> On Thu, May 28, 2020 at 4:56 AM Jonathan M Davis via
>
> Digitalmars-d-announce wrote:
> > As far as I can tell, Walter understands the issues but fundamentally
> > disagrees with pretty much everyone else
On Thu, May 28, 2020 at 4:56 AM Jonathan M Davis via
Digitalmars-d-announce wrote:
>
> As far as I can tell, Walter understands the issues but fundamentally
> disagrees with pretty much everyone else on the issue.
I do not think so, the issue is, that there could be more people who
agree with
17 matches
Mail list logo
