https://issues.dlang.org/show_bug.cgi?id=13727
--- Comment #22 from Dlang Bot ---
@WalterBright updated dlang/dmd pull request #5747 "fix Issue 13727 -
std.stdio.File not thread-safe" fixing this issue:
- fix Issue 13727 - std.stdio.File not thread-safe
https://github.com/dlang/dmd/pull/5747
--
ehavior, just useless behavior. We are better off disallowing it.
>
> "I don't like it" is not a technical argument, and should have no place in a
> technical discussion.
That's not my argument.
> > What does this mean? All individual values are safe according to D
t;I don't like it" is not a technical argument, and should have no place in a
technical discussion.
> What does this mean? All individual values are safe according to D.
If you really believe this, then you do not understand D's memory-safety system
well enough to contribute usefully to thi
https://issues.dlang.org/show_bug.cgi?id=21565
--- Comment #13 from Steven Schveighoffer ---
(In reply to Steven Schveighoffer from comment #12)
> It's just that the rules leave us with the reality that using such unions
> usable in @safe or @trusted code has no utility.
I rewrote this s
cause undefined behavior in @safe-only code? If so, please provide an
> example.
On the grounds that it's not desirable. It does not cause undefined behavior,
just useless behavior. We are better off disallowing it.
> What I have in mind is to change the definition of "unsafe value"
https://issues.dlang.org/show_bug.cgi?id=21565
--- Comment #11 from Paul Backus ---
> Read-only access is fine. Write access is not.
Again, on what grounds do you make this claim? Can writing to the integer
member cause undefined behavior in @safe-only code? If so, please provide an
exam
https://issues.dlang.org/show_bug.cgi?id=21565
--- Comment #10 from Steven Schveighoffer ---
(In reply to Paul Backus from comment #9)
> > I'm disagreeing with the ability of safe code to access any part of this.
>
> On what grounds? The point of @safe is to prevent undefi
https://issues.dlang.org/show_bug.cgi?id=21565
--- Comment #9 from Paul Backus ---
> I'm disagreeing with the ability of safe code to access any part of this.
On what grounds? The point of @safe is to prevent undefined behavior, and
allowing access to the integer cannot possibly l
https://issues.dlang.org/show_bug.cgi?id=21565
--- Comment #8 from Steven Schveighoffer ---
(In reply to RazvanN from comment #5)
> (In reply to Steven Schveighoffer from comment #3)
> > If you do intend to access the int *, then having any safe code anywhere
> > just change th
allow that, then the
> spec's wording does not match its intent, and the wording should be changed.
I'm not disagreeing with the requirement that system/trusted code should be
needed to access aliased values. I'm disagreeing with the ability of safe code
to access any part of this. And the spec currently says that.
> > A struct/union instance is safe when:
> >
> > * the values of its accessible fields are safe, and
> > * it does not introduce unsafe aliasing with unions **that is accessible
> > from @safe code**.
>
> ...then `t`'s value becomes safe, and we are allowe
RazvanN ---
(In reply to Steven Schveighoffer from comment #3)
> A union between a pointer and integer is most definitely unsafe in all
> instances. If you never intend to access the int*, in any circumstance, then
> why have a union?
It may be safe if the user sets the integer part with val
-safe. It contains no undefined behavior. Any @safe function
can call this code with any possible value of `t`, and it will not corrupt
memory. It also accesses both members of `t` and would not compile if annotated
with @safe (i.e., it does not "follow the @safe rules").
The *intent* o
*, then having any safe code anywhere just
change the integer ruins the any safety assumptions that the @trusted or
@system code can make. Essentially, it means @trusted code can never access
such a union reliably except to access just the integer.
This means that T is OK to use ONLY in @system code
from Paul Backus ---
> One might suggest that there is no harm in allowing mutating a scalar that
> overlaps with a pointer if the pointer cannot be accessed. But this is a
> naive view of code. Not all code is @safe, and if @trusted code cannot be
> reasoned about without also having
https://issues.dlang.org/show_bug.cgi?id=21565
ag0aep6g changed:
What|Removed |Added
CC||ag0ae...@gmail.com
--- Comment #1 from ag0aep6g
https://issues.dlang.org/show_bug.cgi?id=21565
Issue ID: 21565
Summary: @safe code allows modification of a scalar that
overlaps with a pointer
Product: D
Version: D2
Hardware: All
OS: All
Status
https://issues.dlang.org/show_bug.cgi?id=21561
--- Comment #2 from Paul Backus ---
Yes, because the data can still be modified by assigning a new value to the
whole union.
---
void oops()
{
U a = { y: 0 };
U b = { x: 1 };
assert(a.y == 0);
a = b;
assert(a.y == 1);
}
---
https://issues.dlang.org/show_bug.cgi?id=21561
Bolpat changed:
What|Removed |Added
CC||qs.il.paperi...@gmail.com
Chloé ---
Note that assigning to the a.x is still prohibited:
---
Error: field `U.x` cannot modify fields in `@safe` code that overlap fields
with other storage classes
---
With that in place, is it necessary to also prohibit accessing the field?
--
https://issues.dlang.org/show_bug.cgi?id=21561
Paul Backus changed:
What|Removed |Added
Keywords||safe
--
https://issues.dlang.org/show_bug.cgi?id=21561
Issue ID: 21561
Summary: Unsafe aliasing of immutable union member allowed in
@safe code
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status
https://issues.dlang.org/show_bug.cgi?id=21546
Bolpat changed:
What|Removed |Added
Keywords||accepts-invalid, safe
CC
https://issues.dlang.org/show_bug.cgi?id=21546
Issue ID: 21546
Summary: ref returning delegate circumvents immutable (@safe
won't help)
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
https://issues.dlang.org/show_bug.cgi?id=21503
Paul Backus changed:
What|Removed |Added
Keywords||safe
--
https://issues.dlang.org/show_bug.cgi?id=21503
Issue ID: 21503
Summary: Incorrect C main signature causes undefined behavior
in @safe code
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status
On Saturday, 5 December 2020 at 18:58:13 UTC, Adam D. Ruppe wrote:
On Saturday, 5 December 2020 at 18:48:19 UTC, tsbockman wrote:
(The documentation for core.thread is broken right now, with
dead links and at least one reference to an example that
doesn't actually appear anywhere on the page.)
On Saturday, 5 December 2020 at 18:48:19 UTC, tsbockman wrote:
(The documentation for core.thread is broken right now, with
dead links and at least one reference to an example that
doesn't actually appear anywhere on the page.)
im not sure about your other question but use my docs they
in the Thread API is annotated
`shared`. Are Thread objects really not thread-safe, and if so
what is the correct way to synchronize access to one?
(The documentation for core.thread is broken right now, with dead
links and at least one reference to an example that doesn't
actually appear
https://issues.dlang.org/show_bug.cgi?id=11048
Mathias LANG changed:
What|Removed |Added
CC||dlang-bugzilla@thecybershad
https://issues.dlang.org/show_bug.cgi?id=13442
Mathias LANG changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
Summary|Default arguments not taken |Default arguments bypass
|into account when being |most attributes check
|called by pure functions|(pure, @safe, @nogc)
--- Comment #3 from Mathias LANG ---
This applies to all attributes but `nothrow`, but only because
https://issues.dlang.org/show_bug.cgi?id=18157
Luís Ferreira changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://issues.dlang.org/show_bug.cgi?id=18110
Issue 18110 depends on issue 18157, which changed state.
Issue 18157 Summary: std.file.rmdirRecurse should be usable in @safe
https://issues.dlang.org/show_bug.cgi?id=18157
What|Removed |Added
Summary|attribute inference accepts |[REG: 2.072] attribute
|unsafe union access as |inference accepts unsafe
|@safe |union access as @safe
Severity|normal |regression
--- Comment #7 from Steven
On Tue, Sep 29, 2020 at 09:56:41AM +, ikod via Digitalmars-d-learn wrote:
> Hello,
>
> Sorry if I unintentionally hurt anybody in this thread.
> I'll try to implement sane and correct iteration behavior for AA
> without noticeable performance loss, and propose it if I succeed.
No feelings
Hello,
Sorry if I unintentionally hurt anybody in this thread.
I'll try to implement sane and correct iteration behavior for AA
without noticeable performance loss, and propose it if I succeed.
Igor
On Sunday, 27 September 2020 at 13:02:04 UTC, Per Nordlöw wrote:
Is it safe to remove AA-elements from an `aa` I'm iterating
over via aa.byKeyValue?
I'm currently doing this:
foreach (ref kv; aa.byKeyValue)
{
if (pred(kv.key))
aa.remove(kv.key); // ok
On 9/28/20 1:18 PM, ikod wrote:
On Monday, 28 September 2020 at 14:58:15 UTC, Steven Schveighoffer wrote:
On 9/27/20 4:43 PM, Per Nordlöw wrote:
On Sunday, 27 September 2020 at 14:23:11 UTC, H. S. Teoh wrote:
No. Modifying a container while iterating over it is, in general, a
bad idea
On Mon, Sep 28, 2020 at 08:04:49PM +, ikod via Digitalmars-d-learn wrote:
> On Monday, 28 September 2020 at 19:18:20 UTC, H. S. Teoh wrote:
[...]
> > The problem with arbitrary, unrestricted modification of a container
> > while iterating over it, is that it inevitably leads to
> >
On Monday, 28 September 2020 at 19:18:20 UTC, H. S. Teoh wrote:
On Mon, Sep 28, 2020 at 05:18:41PM +, ikod via
Digitalmars-d-learn wrote:
On Monday, 28 September 2020 at 14:58:15 UTC, Steven
Schveighoffer wrote:
[...]
> One could write a specific function to iterate and remove. I
This
On Mon, Sep 28, 2020 at 05:18:41PM +, ikod via Digitalmars-d-learn wrote:
> On Monday, 28 September 2020 at 14:58:15 UTC, Steven Schveighoffer wrote:
[...]
> > One could write a specific function to iterate and remove. I
>
> This looks like dead end to me, as you may not only remove items
On Monday, 28 September 2020 at 14:58:15 UTC, Steven
Schveighoffer wrote:
On 9/27/20 4:43 PM, Per Nordlöw wrote:
On Sunday, 27 September 2020 at 14:23:11 UTC, H. S. Teoh wrote:
No. Modifying a container while iterating over it is, in
general, a bad idea (unless the container is designed to be
On 9/27/20 4:43 PM, Per Nordlöw wrote:
On Sunday, 27 September 2020 at 14:23:11 UTC, H. S. Teoh wrote:
No. Modifying a container while iterating over it is, in general, a
bad idea (unless the container is designed to be used that way, but
even then, such removal is generally restricted),
On Monday, 28 September 2020 at 10:01:23 UTC, ikod wrote:
Is it specific to some types? What if collection supports
stable "foreach"?
Yes it depends on how collection members (such as insert, find,
replace, erase, etc) are implemented.
I presume we need attributes on mutating collection
On Monday, 28 September 2020 at 10:10:10 UTC, Per Nordlöw wrote:
On Monday, 28 September 2020 at 10:01:23 UTC, ikod wrote:
Is it specific to some types? What if collection supports
stable "foreach"?
Yes it depends on how collection members (such as insert, find,
replace, erase, etc) are
On Monday, 28 September 2020 at 09:41:02 UTC, Per Nordlöw wrote:
On Monday, 28 September 2020 at 07:15:27 UTC, Imperatorn wrote:
Yes, this should be a compile-time error
Spec here:
https://dlang.org/spec/statement.html#foreach_restrictions
Is it specific to some types? What if collection
On Monday, 28 September 2020 at 07:15:27 UTC, Imperatorn wrote:
Yes, this should be a compile-time error
Spec here:
https://dlang.org/spec/statement.html#foreach_restrictions
On Sunday, 27 September 2020 at 20:43:19 UTC, Per Nordlöw wrote:
On Sunday, 27 September 2020 at 14:23:11 UTC, H. S. Teoh wrote:
[...]
I believe it's high time we start thinking about detecting
these violations at compile-time. I recall it's in the spec
somewhere so we should start a
On Sunday, 27 September 2020 at 14:23:11 UTC, H. S. Teoh wrote:
On Sun, Sep 27, 2020 at 01:02:04PM +, Per Nordlöw via
Digitalmars-d-learn wrote:
Is it safe to remove AA-elements from an `aa` I'm iterating
over via aa.byKeyValue?
No. Modifying a container while iterating over
On Sunday, 27 September 2020 at 14:23:11 UTC, H. S. Teoh wrote:
No. Modifying a container while iterating over it is, in
general, a bad idea (unless the container is designed to be
used that way, but even then, such removal is generally
restricted), because it often leads to highly
On Sun, Sep 27, 2020 at 01:02:04PM +, Per Nordlöw via Digitalmars-d-learn
wrote:
> Is it safe to remove AA-elements from an `aa` I'm iterating over via
> aa.byKeyValue?
No. Modifying a container while iterating over it is, in general, a bad
idea (unless the container is designed to b
On Sunday, 27 September 2020 at 13:02:04 UTC, Per Nordlöw wrote:
Is it safe to remove AA-elements from an `aa` I'm iterating
over via aa.byKeyValue?
I'm currently doing this:
foreach (ref kv; aa.byKeyValue)
{
if (pred(kv.key))
aa.remove(kv.key); // ok
On Sunday, 27 September 2020 at 13:02:04 UTC, Per Nordlöw wrote:
Is it safe to remove AA-elements from an `aa` I'm iterating
over via aa.byKeyValue?
I'm currently doing this:
foreach (ref kv; aa.byKeyValue)
{
if (pred(kv.key))
aa.remove(kv.key); // ok
On Sunday, 27 September 2020 at 13:02:04 UTC, Per Nordlöw wrote:
Is it safe to remove AA-elements from an `aa` I'm iterating
over via aa.byKeyValue?
I'm currently doing this:
foreach (ref kv; aa.byKeyValue)
{
if (pred(kv.key))
aa.remove(kv.key); // ok
Is it safe to remove AA-elements from an `aa` I'm iterating over
via aa.byKeyValue?
I'm currently doing this:
foreach (ref kv; aa.byKeyValue)
{
if (pred(kv.key))
aa.remove(kv.key); // ok?
}
if (aa.length == 0)
aa = null;
Is there a better way?
https://issues.dlang.org/show_bug.cgi?id=21270
Issue ID: 21270
Summary: RedBlackTree fails to instantiate with a type with a
toString taking a @safe sink
Product: D
Version: D2
Hardware: All
OS: All
On Monday, 7 September 2020 at 20:33:26 UTC, 0xEAB wrote:
Are unittests that are marked @safe actually checked for safety?
https://github.com/dlang/phobos/blob/v2.093.1/std/file.d#L4937
How comes this unittest is @safe when `dirEntries` appears to
be @system?
I see what happened now: those
Are unittests that are marked @safe actually checked for safety?
https://github.com/dlang/phobos/blob/v2.093.1/std/file.d#L4937
How comes this unittest is @safe when `dirEntries` appears to be
@system?
Example I:
https://run.dlang.io/is/Vf0STw
Error: @safe function onlineapp.listdir
https://issues.dlang.org/show_bug.cgi?id=13589
Basile-z changed:
What|Removed |Added
Keywords||iasm
CC|
On 6/30/20 6:41 AM, Joseph Rushton Wakeling wrote:
On Sunday, 28 June 2020 at 18:57:22 UTC, Steven Schveighoffer wrote:
Just wanted to post that I finished my update of iopipe to be @safe. I
still have some work to do with std.io so things are more usable (next
on my list is to make standard
On 6/30/20 5:05 AM, aberba wrote:
On Monday, 29 June 2020 at 11:58:10 UTC, Steven Schveighoffer wrote:
and all you have to do is compose the pieces to get it to be a text
iopipe (an iopipe where the window type is a string type).
No sure I understand this statement.
What I mean is, no matter
On Sunday, 28 June 2020 at 18:57:22 UTC, Steven Schveighoffer
wrote:
Just wanted to post that I finished my update of iopipe to be
@safe. I still have some work to do with std.io so things are
more usable (next on my list is to make standard handles
accessible).
Cool, and congratulations
On Monday, 29 June 2020 at 11:58:10 UTC, Steven Schveighoffer
wrote:
On 6/28/20 8:37 PM, aberba wrote:
On Sunday, 28 June 2020 at 20:26:43 UTC, JN wrote:
What's iopipe and what does it do? How does it compare with
std.process?
I my line of words, its what you'd use to stream large files
and
On 6/28/20 8:37 PM, aberba wrote:
On Sunday, 28 June 2020 at 20:26:43 UTC, JN wrote:
What's iopipe and what does it do? How does it compare with std.process?
I my line of words, its what you'd use to stream large files and do
processing on it. Like CSV, video??, Json, and the like. Its high
On Sunday, 28 June 2020 at 20:26:43 UTC, JN wrote:
On Sunday, 28 June 2020 at 18:57:22 UTC, Steven Schveighoffer
wrote:
Just wanted to post that I finished my update of iopipe to be
@safe. I still have some work to do with std.io so things are
more usable (next on my list is to make standard
On 6/28/20 2:57 PM, Steven Schveighoffer wrote:
Just wanted to post that I finished my update of iopipe to be @safe. I
still have some work to do with std.io so things are more usable (next
on my list is to make standard handles accessible).
In this update, I've made it so nearly all
On Sunday, 28 June 2020 at 20:26:43 UTC, JN wrote:
On Sunday, 28 June 2020 at 18:57:22 UTC, Steven Schveighoffer
wrote:
Just wanted to post that I finished my update of iopipe to be
@safe. I still have some work to do with std.io so things are
more usable (next on my list is to make standard
On 6/28/20 4:26 PM, JN wrote:
What's iopipe and what does it do? How does it compare with std.process?
Yeah, I guess I should be more specific in such announcements, sorry!
iopipe is a performance-oriented input/output library for D, which uses
direct buffer access, and provides a similar
On Sunday, 28 June 2020 at 18:57:22 UTC, Steven Schveighoffer
wrote:
Just wanted to post that I finished my update of iopipe to be
@safe. I still have some work to do with std.io so things are
more usable (next on my list is to make standard handles
accessible).
In this update, I've made
Just wanted to post that I finished my update of iopipe to be @safe. I
still have some work to do with std.io so things are more usable (next
on my list is to make standard handles accessible).
In this update, I've made it so nearly all of iopipe can be used in
@safe code. The one exception
John Hall ---
The title of this could be adjusted so that it makes clear that this applies to
all attribute inference. If you change Walter's example from @safe to nothrow,
@nogc, or pure, then you get the same errors.
--
https://issues.dlang.org/show_bug.cgi?id=20956
Mathias LANG changed:
What|Removed |Added
Keywords||industry
--
https://issues.dlang.org/show_bug.cgi?id=20956
Issue ID: 20956
Summary: [DIP1000] @safe defeated by closure capturing ref
parameter
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
#1 from Stanislav Blinov ---
For clarity, you mean modifying `tag` like so?
void unsafe() @safe
{
S s;
__traits(getMember, s, "tag") = 2; // should be error
s.set(42);
}
--
https://issues.dlang.org/show_bug.cgi?id=20941
Issue ID: 20941
Summary: __traits(getMember) should not allow safe code to
access private fields
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
https://issues.dlang.org/show_bug.cgi?id=20937
Issue ID: 20937
Summary: std.range.array of a lengthless range with indirection
is not @safe
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
https://issues.dlang.org/show_bug.cgi?id=20936
Issue ID: 20936
Summary: core.sync.rwmutex should have shared overloads (and
make it usable in @safe code)
Product: D
Version: D2
Hardware: x86_64
OS: Linux
On Saturday, 30 May 2020 at 20:29:37 UTC, Adam D. Ruppe wrote:
We should make this actually work for everything.
1) Make inferred_attr: NOT apply to template/auto functions.
2) Add inverse attributes for all things. (or tri-state,
true/false/null)
3) Solve the child scope problem somehow
https://issues.dlang.org/show_bug.cgi?id=19968
Bolpat changed:
What|Removed |Added
CC||qs.il.paperi...@gmail.com
--- Comment #14 from
https://issues.dlang.org/show_bug.cgi?id=20724
Paul Backus changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On Sunday, 31 May 2020 at 19:15:19 UTC, Walter Bright wrote:
On 5/30/2020 4:39 AM, Nick Treleaven wrote:
To preserve this, then please can we have `@safe module foo;`.
This would change the default on a module basis to @safe, but
still infer e.g. function template bodies as @system where
On 5/30/2020 4:39 AM, Nick Treleaven wrote:
To preserve this, then please can we have `@safe module foo;`. This would change
the default on a module basis to @safe, but still infer e.g. function template
bodies as @system where necessary. This feature would allow modules from
different
|--- |FIXED
--- Comment #3 from Dlang Bot ---
dlang/phobos pull request #7503 "Fix Issue 20874 - std.json.assign requires
'@safe' and 'pure'" was merged into master:
- d816788da4a01df5f03f477e4e96df00aaa5c64e by MoonlightSentinel:
Fix Issue 20874 - std.json.assign requires '@safe'
On Saturday, 30 May 2020 at 20:29:37 UTC, Adam D. Ruppe wrote:
On Saturday, 30 May 2020 at 20:14:04 UTC, Steven Schveighoffer
wrote:
On 5/30/20 4:02 PM, Andrei Alexandrescu wrote:
module foo; @safe:
Again, not the same. Read the full thread that you quoted
above.
And even aside from
On Saturday, 30 May 2020 at 20:14:04 UTC, Steven Schveighoffer
wrote:
On 5/30/20 4:02 PM, Andrei Alexandrescu wrote:
module foo; @safe:
Again, not the same. Read the full thread that you quoted above.
And even aside from inference, it doesn't actually work for most
the attributes.
@safe
On Friday, 29 May 2020 at 05:08:44 UTC, Bruce Carneal wrote:
Thanks Walter.
Thanks to everyone in the commmunity for being nice and saying
"Thank you." As a cautionary tale, Guido Van Rossum, former BDFL
of Python, resigned over flamewars on the := operator in Python,
the same arguments
On 5/30/20 4:02 PM, Andrei Alexandrescu wrote:
On 5/30/20 7:39 AM, Nick Treleaven wrote:
On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
On 5/29/2020 2:07 AM, Timon Gehr wrote:
It would be great if `@safe:` did not affect declarations that would
otherwise infer annotations
On 5/30/20 7:39 AM, Nick Treleaven wrote:
On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
On 5/29/2020 2:07 AM, Timon Gehr wrote:
It would be great if `@safe:` did not affect declarations that would
otherwise infer annotations.
The idea is the simple, general rule
On Saturday, 30 May 2020 at 16:17:49 UTC, Steven Schveighoffer
wrote:
+1 this would be perfect.
Not sure if this would work either, but both of these are
already reserved words:
default @safe:
-Steve
It would probably have to be something more like
`default(@safe)`, since `default @safe
On 5/30/20 7:39 AM, Nick Treleaven wrote:
On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
On 5/29/2020 2:07 AM, Timon Gehr wrote:
It would be great if `@safe:` did not affect declarations that would
otherwise infer annotations.
The idea is the simple, general rule
On Friday, 29 May 2020 at 21:38:40 UTC, Adam D. Ruppe wrote:
On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
The idea is the simple, general rule that:
There's already exceptions to that.
public public void foo() {}
is an error, whereas
public:
public void foo() {}
is not.
On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
On 5/29/2020 2:07 AM, Timon Gehr wrote:
It would be great if `@safe:` did not affect declarations that
would otherwise infer annotations.
The idea is the simple, general rule that:
attribute declaration;
attribute { declaration
On 5/29/2020 2:38 PM, Adam D. Ruppe wrote:
On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
The idea is the simple, general rule that:
There's already exceptions to that.
public public void foo() {}
is an error, whereas
public:
public void foo() {}
is not.
Is it really an
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
On 5/29/2020 2:53 AM, solidstate1991 wrote:
Can we get a compiler flag that will enable safe by default for people who might
want it?
It would balkanize the language.
be that people
were not opposed to "memory safety by default." Instead, they
were opposed to "@safe in its current implementation by
default."
In terms of changing the behavior of @safe, I think it would be
useful to review comments on this old bug report [1] about
changing @safe to
On 5/29/2020 3:36 AM, Ali Çehreli wrote:
Thank you! Which meme did it? :o)
My secret!
On Friday, 29 May 2020 at 20:36:12 UTC, Walter Bright wrote:
Kenny G (famous clarinet player)
Soprano saxophone, not clarinet. They look similar, and are both
Bb instruments (I know there are non Bb clarinets), but they
don't sound that similar to me. Kenny G is also sometimes heard
on
On 5/29/2020 4:47 PM, Bastiaan Veelo wrote:
I’m not sure who in this analogy is the Kenny G and who the Clive Davis,
Haha, I was deliberately vague about that, so people could interpret it as they
pleased.
Off topic, and without extending the analogy, I had never heard about Kenny G
He
601 - 700 of 4431 matches
Mail list logo
