On 06/06/2014 01:15 AM, Walter Bright wrote:
On 6/5/2014 11:09 AM, Steven Schveighoffer wrote:
Thoughts?
Please file bugzilla issue(s) for this.
There already is one:
https://issues.dlang.org/show_bug.cgi?id=8838
On 6/5/2014 11:09 AM, Steven Schveighoffer wrote:
Thoughts?
Please file bugzilla issue(s) for this.
On 6/5/14, 8:30 PM, Timon Gehr wrote:
The fundamental issue seems to lie in methodology and it is that @safe
is approximated by the DMD implementation from the wrong side. Instead
of gradually banning usage of more and more constructs in @safe, the
implementation should have started out with not
On Thursday, 5 June 2014 at 20:37:51 UTC, Steven Schveighoffer
wrote:
On Thu, 05 Jun 2014 16:32:24 -0400, monarch_dodra
wrote:
On Thursday, 5 June 2014 at 19:57:08 UTC, Steven Schveighoffer
wrote:
A possible fix could be to reject the call to ptr at runtime
if the slice is empty.
I don't k
On Thu, 05 Jun 2014 16:32:24 -0400, monarch_dodra
wrote:
On Thursday, 5 June 2014 at 19:57:08 UTC, Steven Schveighoffer wrote:
A possible fix could be to reject the call to ptr at runtime if the
slice is empty.
I don't know why you'd ever do "arr.ptr" in the first place, other than
to a
On Thursday, 5 June 2014 at 19:57:08 UTC, Steven Schveighoffer
wrote:
A possible fix could be to reject the call to ptr at runtime if
the slice is empty.
I don't know why you'd ever do "arr.ptr" in the first place,
other than to avoid the bounds check. So I think the call should
just be unsaf
On Thu, 05 Jun 2014 15:54:33 -0400, Steven Schveighoffer
wrote:
On Thu, 05 Jun 2014 15:48:09 -0400, Steven Schveighoffer
wrote:
On Thu, 05 Jun 2014 15:34:13 -0400, monarch_dodra
wrote:
On Thursday, 5 June 2014 at 19:27:56 UTC, Steven Schveighoffer wrote:
On Thu, 05 Jun 2014 14:47:5
On Thu, 05 Jun 2014 15:48:09 -0400, Steven Schveighoffer
wrote:
On Thu, 05 Jun 2014 15:34:13 -0400, monarch_dodra
wrote:
On Thursday, 5 June 2014 at 19:27:56 UTC, Steven Schveighoffer wrote:
On Thu, 05 Jun 2014 14:47:54 -0400, deadalnix
T[] arr = [ ... ];
arr = arr[$ .. $];
auto garbag
On Thu, 05 Jun 2014 15:34:13 -0400, monarch_dodra
wrote:
On Thursday, 5 June 2014 at 19:27:56 UTC, Steven Schveighoffer wrote:
On Thu, 05 Jun 2014 14:47:54 -0400, deadalnix
T[] arr = [ ... ];
arr = arr[$ .. $];
auto garbage = *(arr.ptr);
Believe it or not, this is actually safe.
What do
On Thursday, 5 June 2014 at 19:27:56 UTC, Steven Schveighoffer
wrote:
On Thu, 05 Jun 2014 14:47:54 -0400, deadalnix
T[] arr = [ ... ];
arr = arr[$ .. $];
auto garbage = *(arr.ptr);
Believe it or not, this is actually safe.
-Steve
What do you mean by "is actually safe" ? In the "can you actu
On Thu, 05 Jun 2014 14:52:39 -0400, Timon Gehr wrote:
On 06/05/2014 08:35 PM, Steven Schveighoffer wrote:
On Thu, 05 Jun 2014 14:30:49 -0400, Timon Gehr
wrote:
The fundamental issue seems to lie in methodology and it is that @safe
is approximated by the DMD implementation from the wrong s
On Thu, 05 Jun 2014 14:47:54 -0400, deadalnix wrote:
On Thursday, 5 June 2014 at 18:33:22 UTC, Timon Gehr wrote:
On 06/05/2014 08:17 PM, deadalnix wrote:
@safe is fundamentally broken.
What's the "fundamental" problem? The construct seems perfectly fit to
specify memory safety in at least
On Thu, 05 Jun 2014 18:17:10 +
deadalnix via Digitalmars-d wrote:
> @safe is fundamentally broken.
@safe as a concept is fine. It's what the compiler currently thinks is or
isn't @safe which is broken. If we can fix that, we should be fine.
- Jonathan M Davis
On Thu, 05 Jun 2014 14:09:44 -0400
Steven Schveighoffer via Digitalmars-d
wrote:
> I propose that we start migrating towards making slicing of stack
> data un-@safe, first by making it a warning, enabled with -w. Then
> making it an error.
I reported this quite some time ago, but unfortunately,
On 06/05/2014 08:35 PM, Steven Schveighoffer wrote:
On Thu, 05 Jun 2014 14:30:49 -0400, Timon Gehr wrote:
The fundamental issue seems to lie in methodology and it is that @safe
is approximated by the DMD implementation from the wrong side. Instead
of gradually banning usage of more and more co
On 06/05/2014 08:47 PM, deadalnix wrote:
On Thursday, 5 June 2014 at 18:33:22 UTC, Timon Gehr wrote:
On 06/05/2014 08:17 PM, deadalnix wrote:
@safe is fundamentally broken.
What's the "fundamental" problem? The construct seems perfectly fit to
specify memory safety in at least the following c
On Thursday, 5 June 2014 at 18:33:22 UTC, Timon Gehr wrote:
On 06/05/2014 08:17 PM, deadalnix wrote:
@safe is fundamentally broken.
What's the "fundamental" problem? The construct seems perfectly
fit to specify memory safety in at least the following context:
void main()@safe{}
:o)
Many
On Thu, 05 Jun 2014 14:30:49 -0400, Timon Gehr wrote:
The fundamental issue seems to lie in methodology and it is that @safe
is approximated by the DMD implementation from the wrong side. Instead
of gradually banning usage of more and more constructs in @safe, the
implementation should hav
On 06/05/2014 08:17 PM, deadalnix wrote:
@safe is fundamentally broken.
What's the "fundamental" problem? The construct seems perfectly fit to
specify memory safety in at least the following context:
void main()@safe{}
:o)
On 06/05/2014 08:09 PM, Steven Schveighoffer wrote:
A quick example:
T[] getBuf(T)() @safe
{
T[100] ret;
auto r = ret[];
return r;
}
void main() @safe
{
auto buf = getBuf!int();
}
Note, the above compiles. An interesting thing here is that we have explicitly
marked getBuf as
@safe is fundamentally broken.
I was just viewing an interesting pull request. The pull wanted to change
a line like this (buf is a fixed-size stack allocated array):
auto x = buf.ptr[0..buf.len];
To this:
auto trustedBuffer(ref typeof(buf) b) @trusted { return b.ptr[0..buf.len];
}
for the sake of allowing the enclosin
22 matches
Mail list logo
