On Wednesday, 28 February 2018 at 22:34:07 UTC, Dukc wrote:
I don't think a just iterated array is automatically set to
null, so taking it's pointer won't hit a memory-proteted area.
So undeprectating arr.ptr in @safe would break @safety and be a
step backward.
If it cannot be proven safe by
I don't think a just iterated array is automatically set to null,
so taking it's pointer won't hit a memory-proteted area. So
undeprectating arr.ptr in @safe would break @safety and be a step
backward.
If this is an issue, one can define a @trusted function which
takes a starting pointer
On 2/27/2018 4:39 AM, Jonathan M Davis wrote:
Except that that's really not how @trusted is supposed to be used. The
programmer needs to verify that the caller is using a.ptr in a manner that
is actually @safe, because the compiler is not smart enough to determine
that for you. Wrapping it in an
On Tuesday, 27 February 2018 at 11:33:04 UTC, Simen Kjærås wrote:
That only checks if the first element is the same. For a full
'is slice' check you'd need something like this:
assert(a.ptr <= b.ptr && b.ptr + b.length <= a.ptr +
a.length);
// Or:
auto c = b.ptr - a.ptr;
> Hm... borrowing from Timothee's suggestion:
> This would be fine and @safe, but may not be useful for all purposes.
> However, it would fix your issue.
how about this: https://github.com/dlang/phobos/pull/6231
On Tue, Feb 27, 2018 at 12:09 PM, Steven Schveighoffer via
Digitalmars-d
On 2/27/18 3:00 PM, Steven Schveighoffer wrote:
On 2/27/18 12:32 PM, Atila Neves wrote:
There's a common case where it's not equivalent - when the pointer is
null. Imagine I have a C function I want to call:
extern(C) void fun(int* things);
Imagine also that it's ok to call with null. Well,
On 2/27/18 12:32 PM, Atila Neves wrote:
There's a common case where it's not equivalent - when the pointer is
null. Imagine I have a C function I want to call:
extern(C) void fun(int* things);
Imagine also that it's ok to call with null. Well, now I can't use a
slice to call this and have
On 02/27/2018 06:32 PM, Atila Neves wrote:
On Tuesday, 27 February 2018 at 12:39:04 UTC, Jonathan M Davis wrote:
[...]
In almost all cases, [0] is equivalent to a.ptr except that it does
bounds checking, so it's actually @safe and thus doesn't need to be
manually verified by the programmer,
On Tuesday, 27 February 2018 at 12:39:04 UTC, Jonathan M Davis
wrote:
On Tuesday, February 27, 2018 04:20:38 Timothee Cour via
Digitalmars-d wrote:
[...]
Except that that's really not how @trusted is supposed to be
used. The programmer needs to verify that the caller is using
a.ptr in a
On 2/27/18 7:20 AM, Timothee Cour wrote:
this would be more bearable if there was a standard @trusted method to
get array `.ptr`, eg:
in `object.d` (so that it's indeed standard)
```
@trusted @nogc pure nothrow
auto pointer(T)(T a){
return a.ptr;
}
```
That completely defeats the purpose
On Tuesday, February 27, 2018 04:20:38 Timothee Cour via Digitalmars-d
wrote:
> this would be more bearable if there was a standard @trusted method to
> get array `.ptr`, eg:
> in `object.d` (so that it's indeed standard)
>
> ```
> @trusted @nogc pure nothrow
> auto pointer(T)(T a){
> return
this would be more bearable if there was a standard @trusted method to
get array `.ptr`, eg:
in `object.d` (so that it's indeed standard)
```
@trusted @nogc pure nothrow
auto pointer(T)(T a){
return a.ptr;
}
```
again, the deprecation message is misleading because `[0]` isn't
equivalent to
On Tuesday, February 27, 2018 11:33:04 Simen Kjærås via Digitalmars-d wrote:
> And trust me, the compiler complains about both of these.
> Possibly rightfully in the first example, but the latter never
> does anything scary with the given pointers.
As I understand it, the way that @safety checks
On Tuesday, 27 February 2018 at 09:58:00 UTC, bauss wrote:
On Tuesday, 27 February 2018 at 09:47:51 UTC, Stefan Koch wrote:
On Tuesday, 27 February 2018 at 09:23:19 UTC, bauss wrote:
On Tuesday, 27 February 2018 at 08:43:32 UTC, Timothee Cour
wrote:
see rationale in
On Tuesday, 27 February 2018 at 09:47:51 UTC, Stefan Koch wrote:
On Tuesday, 27 February 2018 at 09:23:19 UTC, bauss wrote:
On Tuesday, 27 February 2018 at 08:43:32 UTC, Timothee Cour
wrote:
see rationale in
https://issues.dlang.org/show_bug.cgi?id=18529
All I see is a rationale for how it
On Tuesday, 27 February 2018 at 09:23:19 UTC, bauss wrote:
On Tuesday, 27 February 2018 at 08:43:32 UTC, Timothee Cour
wrote:
see rationale in https://issues.dlang.org/show_bug.cgi?id=18529
All I see is a rationale for how it can't be replaced, but not
a rationale for actually doing it.
I
On Tuesday, 27 February 2018 at 08:43:32 UTC, Timothee Cour wrote:
see rationale in https://issues.dlang.org/show_bug.cgi?id=18529
All I see is a rationale for how it can't be replaced, but not a
rationale for actually doing it.
I can't imagine a "safe" situation where you want to do it.
On Tuesday, 27 February 2018 at 08:43:32 UTC, Timothee Cour wrote:
see rationale in https://issues.dlang.org/show_bug.cgi?id=18529
It looks like the actual deprecation was made with this PR:
https://github.com/dlang/dmd/pull/5860 Meaning it's been
deprecated for more than a year and a
18 matches
Mail list logo
