On Wednesday, 25 January 2017 at 22:59:55 UTC, Jonathan M Davis
wrote:
So, yes, if all you're planning to do is look at the pointer to
the first element in the array, then [0] is safer, but odds
are quite low that that's actually what you're going to do, and
in all of the other cases, you
On Tuesday, 24 January 2017 at 12:01:35 UTC, Jonathan M Davis
wrote:
So, while it makes sense to say that .ptr can't be used in
@safe code, it really doesn't make sense to suggest [0] as
an alternative.
- Jonathan M Davis
Sure I see your point. But I feel like deprecations should also
list
On Wednesday, 25 January 2017 at 22:59:55 UTC, Jonathan M Davis
wrote:
Yes, but my point is that you're normally only going to use
.ptr to pass something to a C function, and even if you're
doing more with it in D, odds are, you're going to be doing
pointer arithmetic.
Wrong again. If this
On Wednesday, 25 January 2017 at 23:09:11 UTC, David Nadlinger
wrote:
This is a fallacy:
Ah, yes indeed, that was mentioned earlier in the thread too, it
just slipped my mind again.
On Wednesday, 25 January 2017 at 22:54:32 UTC, Adam D. Ruppe
wrote:
On Wednesday, 25 January 2017 at 22:46:10 UTC, David Nadlinger
wrote:
This is because every pointer in SafeD is dereferencable.
But null pointers are allowed in SafeD and arr.ptr is either
arr[0] or null
This is a
On Wednesday, 25 January 2017 at 18:12:18 UTC, Jonathan M Davis
wrote:
Fine, but in the vast majority of cases, you're calling .ptr,
because you're going to be passing the pointer to C code, in
which case, doing [0] buys you very little, since the C
code is inevitably going to be reading more
On Wednesday, January 25, 2017 22:46:10 David Nadlinger via Digitalmars-d-
learn wrote:
> On Tuesday, 24 January 2017 at 11:38:16 UTC, Jonathan M Davis
>
> wrote:
> > It seems _slightly_ better from a safety perspective but only
> > slightly.
>
> Wrong – one is correct, the other is not. This is
On Wednesday, 25 January 2017 at 22:46:10 UTC, David Nadlinger
wrote:
This is because every pointer in SafeD is dereferencable.
But null pointers are allowed in SafeD and arr.ptr is either
arr[0] or null
On Tuesday, 24 January 2017 at 11:38:16 UTC, Jonathan M Davis
wrote:
It seems _slightly_ better from a safety perspective but only
slightly.
Wrong – one is correct, the other is not. This is because every
pointer in SafeD is dereferencable. Pointer arithmetic is not
allowed in SafeD, so your
On Wednesday, January 25, 2017 10:52:51 Kagamin via Digitalmars-d-learn
wrote:
> On Tuesday, 24 January 2017 at 12:01:35 UTC, Jonathan M Davis
>
> wrote:
> > So, while it makes sense to say that .ptr can't be used in
> > @safe code, it really doesn't make sense to suggest [0] as
> > an
On Tuesday, 24 January 2017 at 12:01:35 UTC, Jonathan M Davis
wrote:
So, while it makes sense to say that .ptr can't be used in
@safe code, it really doesn't make sense to suggest [0] as
an alternative.
When you ensure pointers point to existing data, you can
dereference them in safe code,
On Tuesday, 24 January 2017 at 12:01:35 UTC, Jonathan M Davis
wrote:
So, while it makes sense to say that .ptr can't be used in
@safe code, it really doesn't make sense to suggest [0] as
an alternative.
That may well be. But I believe everything that can provably be
@safe are made so even
On Tuesday, January 24, 2017 11:50:16 Rene Zwanenburg via Digitalmars-d-
learn wrote:
> On Tuesday, 24 January 2017 at 11:38:16 UTC, Jonathan M Davis
>
> wrote:
> > Likely because it does bounds checking, so you at least know
> > that it's not null. But I don't see why that would really
> >
On Tuesday, 24 January 2017 at 11:38:16 UTC, Jonathan M Davis
wrote:
Likely because it does bounds checking, so you at least know
that it's not null. But I don't see why that would really
improve much considering that the odds are that you're really
going to be accessing far more than just the
On Tuesday, 24 January 2017 at 11:32:47 UTC, TheFlyingFiddle
wrote:
On Tuesday, 24 January 2017 at 11:28:17 UTC, Atila Neves wrote:
void main() {
foo;
}
void foo() @safe {
int[] array;
auto ptr = array.ptr;
}
foo.d(7): Deprecation: array.ptr cannot be used in @safe code,
use [0]
On Tuesday, January 24, 2017 11:28:17 Atila Neves via Digitalmars-d-learn
wrote:
> void main() {
> foo;
> }
>
> void foo() @safe {
> int[] array;
> auto ptr = array.ptr;
> }
>
>
> foo.d(7): Deprecation: array.ptr cannot be used in @safe code,
> use [0] instead
>
>
> [0] is
On Tuesday, 24 January 2017 at 11:28:17 UTC, Atila Neves wrote:
void main() {
foo;
}
void foo() @safe {
int[] array;
auto ptr = array.ptr;
}
foo.d(7): Deprecation: array.ptr cannot be used in @safe code,
use [0] instead
[0] is incredibly ugly and feels like an unnecessary
On Tuesday, 24 January 2017 at 11:28:17 UTC, Atila Neves wrote:
void main() {
foo;
}
void foo() @safe {
int[] array;
auto ptr = array.ptr;
}
foo.d(7): Deprecation: array.ptr cannot be used in @safe code,
use [0] instead
[0] is incredibly ugly and feels like an unnecessary
void main() {
foo;
}
void foo() @safe {
int[] array;
auto ptr = array.ptr;
}
foo.d(7): Deprecation: array.ptr cannot be used in @safe code,
use [0] instead
[0] is incredibly ugly and feels like an unnecessary hack,
and I'm wondering why it's @safe.
Atila
19 matches
Mail list logo
