On Tuesday, 18 February 2014 at 23:45:37 UTC, Andrei Alexandrescu
wrote:
On 2/19/14, 12:20 AM, "Nordlöw" wrote:
I have no experience in writing threadlocking queues.
I of course mean lock-free queues.
/Per
std.allocator has one.
Andrei
I'd say "upcoming std.allocator will have one". It's
On 2/19/14, 12:20 AM, "Nordlöw" wrote:
I have no experience in writing threadlocking queues.
I of course mean lock-free queues.
/Per
std.allocator has one.
Andrei
On Tuesday, 18 February 2014 at 21:37:09 UTC, Nordlöw wrote:
On Tuesday, 18 February 2014 at 21:21:54 UTC, deadalnix wrote:
On Tuesday, 18 February 2014 at 21:05:38 UTC, Nordlöw wrote:
What's the best solution to communicate between threads in D
today if I care about
1. Security & Correctness
I have no experience in writing threadlocking queues.
I of course mean lock-free queues.
/Per
On Tuesday, 18 February 2014 at 21:21:54 UTC, deadalnix wrote:
On Tuesday, 18 February 2014 at 21:05:38 UTC, Nordlöw wrote:
What's the best solution to communicate between threads in D
today if I care about
1. Security & Correctness?
2. Performance?
and are these mutually exclusive?
Does Pho
On Tuesday, 18 February 2014 at 21:05:38 UTC, Nordlöw wrote:
What's the best solution to communicate between threads in D
today if I care about
1. Security & Correctness?
2. Performance?
and are these mutually exclusive?
Does Phobos or other library contain lockfree queues?
From what I can s
On Tuesday, 18 February 2014 at 21:05:38 UTC, Nordlöw wrote:
What's the best solution to communicate between threads in D
today if I care about
1. Security & Correctness?
2. Performance?
and are these mutually exclusive?
Does Phobos or other library contain lockfree queues?
From what I can s
What's the best solution to communicate between threads in D
today if I care about
1. Security & Correctness?
2. Performance?
and are these mutually exclusive?
Does Phobos or other library contain lockfree queues?
From what I can see std.concurrent.MessageBox requires
Mutex-locking. Is this
Andrei Alexandrescu:
We are considering making non-nullables the default, @nullable
to mark optionally null objects, and enable the related checks
with an opt-in compiler flag.
It's a significant transition, very interesting. I think it could
be for the better (I asked something related time
useful, but it doesn't fit well with
D's design with regards to init values, and making them the default seems like
a disaster to me.
And if we were going to start changing defaults, I would have thought that
making pure, @safe, and/or nothrow the default would be a lot more beneficial
given how they have to be used absolutely everywhere if you want to do
anything with them.
- Jonathan M Davis
On 2014-02-03 11:41, Jonathan M Davis wrote:
I recall there being a change to druntime such that it would print a backtrace
for you if you hit a segfault, but it doesn't seem to work when I write a
quick test program which segfaults, so I'm not sure what happened to that.
1. It only works on L
On Wednesday, 5 February 2014 at 03:12:57 UTC, Adam D. Ruppe
wrote:
On Tuesday, 4 February 2014 at 22:57:06 UTC, Idan Arye wrote:
So what you are saying is that it should be implemented in the
core language(`@nullable`), and than wrapped in the standard
library(`Nullable!`) so we can have the b
On Tuesday, 4 February 2014 at 16:00:20 UTC, Meta wrote:
I'm interested in how this might fit in with your recent
discovery in this thread:
http://forum.dlang.org/thread/majnjuhxdefjuqjlp...@forum.dlang.org?page=1
There's a lot of potential for pluggable semantic checks with
that. Earlier to
On Tuesday, 4 February 2014 at 22:57:06 UTC, Idan Arye wrote:
So what you are saying is that it should be implemented in the
core language(`@nullable`), and than wrapped in the standard
library(`Nullable!`) so we can have the benefit of using D's
and Phobos' rich template-handling functionality
On Tuesday, 4 February 2014 at 18:26:10 UTC, deadalnix wrote:
static if(isReferenceType!T) {
union {
T t;
typeof(null) __;
}
}
cool, that would work. @nullable is now totally dead to me.
* Consistency with all other types. Nullable!int works,
Nullable!Object can be pas
On Tuesday, 4 February 2014 at 14:54:35 UTC, Adam D. Ruppe wrote:
On Tuesday, 4 February 2014 at 14:34:49 UTC, Idan Arye wrote:
Probably because `Nullable!` suggests that's it's a library
solution - and it isn't.
It should be. The way I'd do it is
Object o; // not null
@nullable Object o; //
On Tuesday, 4 February 2014 at 14:54:35 UTC, Adam D. Ruppe wrote:
This gives us:
* Implementation help - no binary cost for Nullable!Object
since it just uses null directly instead of a bool isNull field
(the optimizer also knows this)
static if(isReferenceType!T) {
union {
T t
On 2/4/14, 6:54 AM, Adam D. Ruppe wrote:
On Tuesday, 4 February 2014 at 14:34:49 UTC, Idan Arye wrote:
Probably because `Nullable!` suggests that's it's a library solution -
and it isn't.
It should be. The way I'd do it is
Object o; // not null
@nullable Object o; // like we have today
BUT,
On Tuesday, 4 February 2014 at 13:44:00 UTC, Idan Arye wrote:
On Tuesday, 4 February 2014 at 13:20:12 UTC, Dicebot wrote:
On Tuesday, 4 February 2014 at 13:11:49 UTC, Idan Arye wrote:
Why is `bar(w);` an error? I may be perfectly valid for `bar`
to accept null as argument.
It should declare i
On 2/4/14, 12:32 AM, deadalnix wrote:
On Tuesday, 4 February 2014 at 06:49:57 UTC, Andrei Alexandrescu wrote:
That would be awesome. The breakage involved, is quite high however.
No breakage if the opt-in flag is not used.
Andrei
OK, If you are willing to do that change, I'm 200% behind !
On Tuesday, 4 February 2014 at 14:54:35 UTC, Adam D. Ruppe wrote:
On Tuesday, 4 February 2014 at 14:34:49 UTC, Idan Arye wrote:
Probably because `Nullable!` suggests that's it's a library
solution - and it isn't.
It should be. The way I'd do it is
Object o; // not null
@nullable Object o; //
On Tuesday, 4 February 2014 at 14:54:35 UTC, Adam D. Ruppe wrote:
On Tuesday, 4 February 2014 at 14:34:49 UTC, Idan Arye wrote:
Probably because `Nullable!` suggests that's it's a library
solution - and it isn't.
It should be. The way I'd do it is
Object o; // not null
@nullable Object o; //
On Tuesday, 4 February 2014 at 14:34:49 UTC, Idan Arye wrote:
Probably because `Nullable!` suggests that's it's a library
solution - and it isn't.
It should be. The way I'd do it is
Object o; // not null
@nullable Object o; // like we have today
BUT, user code would never use that. Instead, w
On Tuesday, 4 February 2014 at 08:32:26 UTC, deadalnix wrote:
On Tuesday, 4 February 2014 at 06:49:57 UTC, Andrei
Alexandrescu wrote:
That would be awesome. The breakage involved, is quite high
however.
No breakage if the opt-in flag is not used.
Andrei
OK, If you are willing to do that cha
On Tuesday, 4 February 2014 at 13:20:12 UTC, Dicebot wrote:
On Tuesday, 4 February 2014 at 13:11:49 UTC, Idan Arye wrote:
Why is `bar(w);` an error? I may be perfectly valid for `bar`
to accept null as argument.
It should declare its argument as Nullable!w then.
If non-null-by-default will b
On Tuesday, 4 February 2014 at 13:11:49 UTC, Idan Arye wrote:
Why is `bar(w);` an error? I may be perfectly valid for `bar`
to accept null as argument.
It should declare its argument as Nullable!w then.
On Tuesday, 4 February 2014 at 02:27:23 UTC, deadalnix wrote:
On Tuesday, 4 February 2014 at 01:09:52 UTC, Meta wrote:
On Monday, 3 February 2014 at 23:34:59 UTC, deadalnix wrote:
On Monday, 3 February 2014 at 22:23:52 UTC, Meta wrote:
If null is an invalid value to assign to a pointer, then
t
On Tuesday, 4 February 2014 at 06:49:57 UTC, Andrei Alexandrescu
wrote:
That would be awesome. The breakage involved, is quite high
however.
No breakage if the opt-in flag is not used.
Andrei
OK, If you are willing to do that change, I'm 200% behind !
Question, why do you propose to use @nu
On Tuesday, 4 February 2014 at 06:03:14 UTC, Andrei Alexandrescu
wrote:
On 2/3/14, 9:09 PM, Jonathan M Davis wrote:
I truly hope that that's never the case. Adding non-nullable
references to the
language is one thing; making them the default is quite
another, and making
them the default would b
On 2/3/14, 10:22 PM, deadalnix wrote:
On Tuesday, 4 February 2014 at 06:03:14 UTC, Andrei Alexandrescu wrote:
On 2/3/14, 9:09 PM, Jonathan M Davis wrote:
I truly hope that that's never the case. Adding non-nullable
references to the
language is one thing; making them the default is quite anothe
On Tuesday, 4 February 2014 at 06:03:14 UTC, Andrei Alexandrescu
wrote:
On 2/3/14, 9:09 PM, Jonathan M Davis wrote:
I truly hope that that's never the case. Adding non-nullable
references to the
language is one thing; making them the default is quite
another, and making
them the default would b
his field > page size.
In this solution there will be very little overhead cause it is
very rare case that structures have size > page size.
Sorry for my bad english. :)
In that case there will be no need for dissallowing null pointers
in safe code.
Some suggesting to compiler checking for that case.
If talking about Linux OS it reserves first page (4kb on 32bit
cpu, 8kb on 64) for null fault case (try to dereference pointer
in that memory addresses will cause segmentation fault or smth
like this).
So compiler can check (at compile time
On 2/3/14, 9:09 PM, Jonathan M Davis wrote:
I truly hope that that's never the case. Adding non-nullable references to the
language is one thing; making them the default is quite another, and making
them the default would break existing code. And given Walter's normal stance
on code breakage, I'd
On Monday, February 03, 2014 22:23:51 Meta wrote:
> On Monday, 3 February 2014 at 22:18:35 UTC, Jonathan M Davis
>
> wrote:
> > For it to know, it would have to examine the body of foo (which
> > it doesn't
> > necessarily have the code for under C's compilation model -
> > which D uses), and
> >
On Sunday, February 02, 2014 17:41:58 Meta wrote:
> > True, but I don't even agree that null pointers are that big a
> > deal in the
> > first place. If we really want to add non-nullable pointers or
> > references to
> > the language, then we can. I don't think that that's
> > necessarily a bad id
On Tuesday, 4 February 2014 at 01:09:52 UTC, Meta wrote:
On Monday, 3 February 2014 at 23:34:59 UTC, deadalnix wrote:
On Monday, 3 February 2014 at 22:23:52 UTC, Meta wrote:
If null is an invalid value to assign to a pointer, then
there's no issue.
int* foo()
{
//Error: cannot implicitly co
On Monday, 3 February 2014 at 23:34:59 UTC, deadalnix wrote:
On Monday, 3 February 2014 at 22:23:52 UTC, Meta wrote:
If null is an invalid value to assign to a pointer, then
there's no issue.
int* foo()
{
//Error: cannot implicitly convert typeof(null) to type int*
return "/etc/foo".exis
On Monday, 3 February 2014 at 22:23:52 UTC, Meta wrote:
If null is an invalid value to assign to a pointer, then
there's no issue.
int* foo()
{
//Error: cannot implicitly convert typeof(null) to type int*
return "/etc/foo".exists ? new int : null;
}
Only cross abstraction boundaries i
On 2/3/2014 12:46 PM, Ary Borenszweig wrote:
On 2/3/14, 5:56 AM, Walter Bright wrote:
On 2/3/2014 12:00 AM, Uranuz wrote:
At the current state OS send SEGFAULT message and I can't
even get some info where is the source of problem.
1. Compile with symbolic debug info on (-g switch)
2. Run und
This is fantastic news, Andrei!
It's all about provably correct code like Walter often brings up
on his talks.
If/When this arrives, D will become an even more suitable
replacement for safety critical languages like Ada.
On Monday, 3 February 2014 at 22:18:35 UTC, Jonathan M Davis
wrote:
For it to know, it would have to examine the body of foo (which
it doesn't
necessarily have the code for under C's compilation model -
which D uses), and
even if it did that wouldn't be enough e.g.
int* foo()
{
return "/et
On Monday, February 03, 2014 09:30:32 Ary Borenszweig wrote:
> On 2/1/14, 7:14 AM, Jonathan M Davis wrote:
> > In the general case, you can only catch it at compile time if you disallow
> > it completely, which is unnecessarily restrictive. Sure, some basic cases
> > can be caught, but unless the c
On 2/3/14, 5:56 AM, Walter Bright wrote:
On 2/3/2014 12:00 AM, Uranuz wrote:
At the current state OS send SEGFAULT message and I can't
even get some info where is the source of problem.
1. Compile with symbolic debug info on (-g switch)
2. Run under a debugger, such as gdb
3. When it seg fau
On Monday, 3 February 2014 at 12:41:30 UTC, Pavel wrote:
struct T {
ubyte[0x12FDB5/*address of local x in main + 1*/] x;
}
@safe void test() {
T* t = null;
t.x[$-1] = 99;
}
void main() {
ubyte x = 0;
writeln("\n", &x, '
struct T {
ubyte[0x12FDB5/*address of local x in main + 1*/] x;
}
@safe void test() {
T* t = null;
t.x[$-1] = 99;
}
void main() {
ubyte x = 0;
writeln("\n", &x, ' ', x);
test();
writeln("\n", x);
}
On 2/1/14, 7:14 AM, Jonathan M Davis wrote:
In the general case, you can only catch it at compile time if you disallow it
completely, which is unnecessarily restrictive. Sure, some basic cases can be
caught, but unless the code where the pointer/reference is defined is right
next to the code wher
On Monday, February 03, 2014 00:56:05 Walter Bright wrote:
> On 2/3/2014 12:00 AM, Uranuz wrote:
> > At the current state OS send SEGFAULT message and I can't
> > even get some info where is the source of problem.
>
> 1. Compile with symbolic debug info on (-g switch)
>
> 2. Run under a debugger,
On Saturday, 1 February 2014 at 18:58:11 UTC, Andrei Alexandrescu
wrote:
It also became clear that a library solution would improve
things but cannot compete with a language solution.
I'm really shocked! This issue must be way bigger than I think,
if even Andrei is asking for a language solution
On 2/3/2014 12:00 AM, Uranuz wrote:
At the current state OS send SEGFAULT message and I can't
even get some info where is the source of problem.
1. Compile with symbolic debug info on (-g switch)
2. Run under a debugger, such as gdb
3. When it seg faults, type:
bt
and it will give you a
I'm not sure what to do about null references. One of my ideas is
that some type of Exception or Throwable object should be thrown
when accessing null pointer instead of getting SEGFAULT. In this
way programmer can handle exception at application level, get
some information about problem and ma
On Monday, 3 February 2014 at 03:49:20 UTC, Andrei Alexandrescu
wrote:
No matter. The point is the dereference will not be dead to the
optimizer.
Andrei
I see. But how would you add these without adding thousand of
them all over the place ?
On 2/2/14, 5:47 PM, deadalnix wrote:
On Sunday, 2 February 2014 at 23:55:48 UTC, Andrei Alexandrescu wrote:
On 2/2/14, 3:44 PM, Timon Gehr wrote:
On 02/03/2014 12:09 AM, Andrei Alexandrescu wrote:
A front-end pass could replace the dead dereference with a guard that
asserts the reference is n
On Sunday, 2 February 2014 at 23:55:48 UTC, Andrei Alexandrescu
wrote:
On 2/2/14, 3:44 PM, Timon Gehr wrote:
On 02/03/2014 12:09 AM, Andrei Alexandrescu wrote:
A front-end pass could replace the dead dereference with a
guard that
asserts the reference is not null.
I don't think this would
On 2/2/14, 3:44 PM, Timon Gehr wrote:
On 02/03/2014 12:09 AM, Andrei Alexandrescu wrote:
A front-end pass could replace the dead dereference with a guard that
asserts the reference is not null.
I don't think this would be feasible. (The front-end pass would need to
simulate all back-end passe
On 02/03/2014 12:09 AM, Andrei Alexandrescu wrote:
A front-end pass could replace the dead dereference with a guard that
asserts the reference is not null.
I don't think this would be feasible. (The front-end pass would need to
simulate all back-end passes in order to find all the references
On 2/2/14, 1:23 PM, deadalnix wrote:
On Sunday, 2 February 2014 at 10:58:51 UTC, Dicebot wrote:
On Sunday, 2 February 2014 at 03:45:06 UTC, Andrei Alexandrescu wrote:
On 2/1/14, 7:35 PM, deadalnix wrote:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
Whoa, thanks.
On Sunday, 2 February 2014 at 09:56:06 UTC, Marc Schütz wrote:
auto x = *p;
if(!p) {
do_something(x);
}
In the first step, the if-block will be removed, because its
condition is "known" to be false. After that, the value stored
into x is unused, and the dereference can get removed too.
On 2/2/2014 1:19 PM, deadalnix wrote:
But in
our case, it imply that the optimizer won't be able to optimize away load that
it can't prove won't trap. That mean the compiler won"t be able to optimize most
load.
I do understand that issue, but I'm not sure what the solution is.
On Sunday, 2 February 2014 at 10:58:51 UTC, Dicebot wrote:
On Sunday, 2 February 2014 at 03:45:06 UTC, Andrei Alexandrescu
wrote:
On 2/1/14, 7:35 PM, deadalnix wrote:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
Whoa, thanks. So the compiler figures null pointer de
On Sunday, 2 February 2014 at 07:54:26 UTC, Jonathan M Davis
wrote:
On Saturday, February 01, 2014 19:44:44 Andrei Alexandrescu
wrote:
On 2/1/14, 7:35 PM, deadalnix wrote:
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
Whoa, thanks. So the compiler figures null point
On Sunday, 2 February 2014 at 18:33:05 UTC, Adam D. Ruppe wrote:
On Sunday, 2 February 2014 at 15:06:34 UTC, Idan Arye wrote:
I think it's safe to assume that you - being a supporter of
the non-null movement - write your own code in a way that
tries to avoid the usage of null as mu
On Sunday, 2 February 2014 at 15:06:34 UTC, Idan Arye wrote:
I think it's safe to assume that you - being a supporter of the
non-null movement - write your own code in a way that tries to
avoid the usage of null as much as possible.
You'd be wrong - I was against the not null thing
On Sunday, 2 February 2014 at 12:42:47 UTC, Jonathan M Davis
wrote:
On Sunday, February 02, 2014 12:52:44 Timon Gehr wrote:
On 02/02/2014 04:39 AM, Jonathan M Davis wrote:
> I'm not sure how I feel about that, particularly since I
> haven't seen such
> data myself. My natural reaction when peop
s of contracts - it would be the
"worth it" kind of breakage.
I think it's safe to assume that you - being a supporter of the
non-null movement - write your own code in a way that tries to
avoid the usage of null as much as possible. Other people - like
me - treat null as a val
On 02/02/2014 01:42 PM, Jonathan M Davis wrote:
On Sunday, February 02, 2014 12:52:44 Timon Gehr wrote:
On 02/02/2014 04:39 AM, Jonathan M Davis wrote:
I'm not sure how I feel about that, particularly since I haven't seen such
data myself. My natural reaction when people complain about null poi
On Sunday, 2 February 2014 at 13:15:42 UTC, Dicebot wrote:
I agree that there is no much benefit in opt-in null-free
pointers. But if making those opt-out would have been possible,
I'd love it. Breaks every single D program out there though.
This isn't necessarily so bad. My biggest chunk of c
On Sunday, 2 February 2014 at 13:18:19 UTC, Nick Treleaven wrote:
I read your recent post about this, it was interesting. But I
don't think you can disallow this:
auto cn = checkNull(cast(C)null);
NotNull!C nn = cn;
obj2 is then null, when it shouldn't be allowed.
It wouldn't be null
On 02/02/2014 13:18, Nick Treleaven wrote:
auto cn = checkNull(cast(C)null);
NotNull!C nn = cn;
obj2 is then null, when it shouldn't be allowed.
Oops, I meant nn, not obj2.
On 01/02/2014 22:05, Adam D. Ruppe wrote:
On Saturday, 1 February 2014 at 18:58:11 UTC, Andrei Alexandrescu wrote:
Widget w = fetchWidget();
if (w)
{
... here w is automatically inferred as non-null ...
}
A library solution to this exists already:
Widget wn = fetchWidg
On Sunday, 2 February 2014 at 12:42:47 UTC, Jonathan M Davis
wrote:
But I doubt that I'll use them often, and I do think that the
whole issue is
frequently blown out of proportion.
- Jonathan M Davis
I agree that there is no much benefit in opt-in null-free
pointers. But if making those opt-
On Sunday, February 02, 2014 12:52:44 Timon Gehr wrote:
> On 02/02/2014 04:39 AM, Jonathan M Davis wrote:
> > I'm not sure how I feel about that, particularly since I haven't seen such
> > data myself. My natural reaction when people complain about null pointer
> > problems is that they're sloppy p
On 02/02/2014 04:39 AM, Jonathan M Davis wrote:
I'm not sure how I feel about that, particularly since I haven't seen such
data myself. My natural reaction when people complain about null pointer
problems is that they're sloppy programmers (which isn't necessarily fair, but
that's my natural reac
On Sunday, 2 February 2014 at 03:45:06 UTC, Andrei Alexandrescu
wrote:
On 2/1/14, 7:35 PM, deadalnix wrote:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
Whoa, thanks. So the compiler figures null pointer dereference
in C is undefined behavior, which means the entir
On Sunday, 2 February 2014 at 07:54:26 UTC, Jonathan M Davis
wrote:
On Saturday, February 01, 2014 19:44:44 Andrei Alexandrescu
wrote:
On 2/1/14, 7:35 PM, deadalnix wrote:
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
Whoa, thanks. So the compiler figures null point
On Saturday, February 01, 2014 19:44:44 Andrei Alexandrescu wrote:
> On 2/1/14, 7:35 PM, deadalnix wrote:
> > http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
>
> Whoa, thanks. So the compiler figures null pointer dereference in C is
> undefined behavior, which means the en
On Saturday, February 01, 2014 19:40:26 Andrei Alexandrescu wrote:
> On 2/1/14, 7:29 PM, Jonathan M Davis wrote:
> > Sure, and there are other things that the compiler can do to catch null
> > dereferences (e.g. look at the first dereferencing of the pointer in the
> > function that it's declared i
On Saturday, 1 February 2014 at 22:05:21 UTC, Adam D. Ruppe wrote:
On Saturday, 1 February 2014 at 18:58:11 UTC, Andrei
Alexandrescu wrote:
Widget w = fetchWidget();
if (w)
{
... here w is automatically inferred as non-null ...
}
A library solution to this exists already:
W
On Sunday, 2 February 2014 at 00:50:28 UTC, Timon Gehr wrote:
if(auto w = wn.checkNull){
// ...
}else w.foo();
(presumably you meant wn.foo, as w would be out of scope in the
else branch)
This is more a question of the default than the library though,
as all other things being equal, ch
On 2/1/14, 7:35 PM, deadalnix wrote:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
Whoa, thanks. So the compiler figures null pointer dereference in C is
undefined behavior, which means the entire program could do whatever if
that does happen.
Andrei
will segfault and kill your program, not corrupt
memory. It can't even read any memory. It's a bug to dereference a null
pointer or reference, but it's not unsafe, because it can't access _any_
memory, let alone memory that it's not supposed to be accessing, which is
precisel
On Sunday, 2 February 2014 at 03:35:25 UTC, deadalnix wrote:
Do you have any pointers to substantiate that? I find such a
behavior rather bizarre.
Andrei
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
Also it has to be noted that this very phenomena caused a
secur
On Sunday, 2 February 2014 at 03:27:21 UTC, Andrei Alexandrescu
wrote:
On 2/1/14, 5:17 PM, deadalnix wrote:
On Sunday, 2 February 2014 at 01:01:25 UTC, Andrei
Alexandrescu wrote:
On 2/1/14, 1:40 PM, deadalnix wrote:
On Saturday, 1 February 2014 at 20:09:13 UTC, Andrei
Alexandrescu wrote:
This
On Saturday, February 01, 2014 10:58:12 Andrei Alexandrescu wrote:
> On 1/31/14, 5:39 PM, Jonathan M Davis wrote:
> > Regardless, we're not adding anything with regards to non-nullable
> > references to the language itself [...]
>
> I think the sea is changing here. I've collected hard data that r
On 2/1/14, 5:17 PM, deadalnix wrote:
On Sunday, 2 February 2014 at 01:01:25 UTC, Andrei Alexandrescu wrote:
On 2/1/14, 1:40 PM, deadalnix wrote:
On Saturday, 1 February 2014 at 20:09:13 UTC, Andrei Alexandrescu wrote:
This has been discussed to death a number of times. A field access
obj.field
It will segfault and kill your program, not corrupt
> > memory. It can't even read any memory. It's a bug to dereference a null
> > pointer or reference, but it's not unsafe, because it can't access _any_
> > memory, let alone memory that it's not supposed to be
ks.
The same is likely to go for any in operator that's looking to be efficient.
Do you propose that the in operator be @system?
It's too restrictive for pointers or references to be @system and making them
@system under any kind of normal circumstances would be a huge blow to @safe.
On Sunday, 2 February 2014 at 01:01:25 UTC, Andrei Alexandrescu
wrote:
On 2/1/14, 1:40 PM, deadalnix wrote:
On Saturday, 1 February 2014 at 20:09:13 UTC, Andrei
Alexandrescu wrote:
This has been discussed to death a number of times. A field
access
obj.field will use addressing with a constant o
On 2/1/14, 1:40 PM, deadalnix wrote:
On Saturday, 1 February 2014 at 20:09:13 UTC, Andrei Alexandrescu wrote:
This has been discussed to death a number of times. A field access
obj.field will use addressing with a constant offset. If that offset
is larger than the lowest address allowed to the a
On 02/01/2014 11:05 PM, Adam D. Ruppe wrote:
A library solution to this exists already:
Widget wn = fetchWidget();
if(auto w = wn.checkNull) {
// w implicitly converts to NotNull!Widget
}
I've had some difficulty in const correctness with my implementation...
but const correct is an entire
On Saturday, 1 February 2014 at 20:03:40 UTC, Jonathan M Davis
wrote:
In the general case, you can only catch it at compile time if
you disallow it
completely, which is unnecessarily restrictive.
That is not accurate. The proposal here propose to make it
@system instead of disallowing it comp
On Saturday, 1 February 2014 at 18:58:11 UTC, Andrei Alexandrescu
wrote:
Widget w = fetchWidget();
if (w)
{
... here w is automatically inferred as non-null ...
}
A library solution to this exists already:
Widget wn = fetchWidget();
if(auto w = wn.checkNull) {
// w i
On Saturday, 1 February 2014 at 18:58:11 UTC, Andrei Alexandrescu
wrote:
On 1/31/14, 5:39 PM, Jonathan M Davis wrote:
Regardless, we're not adding anything with regards to
non-nullable references
to the language itself [...]
I think the sea is changing here. I've collected hard data that
rev
On Saturday, 1 February 2014 at 20:09:13 UTC, Andrei Alexandrescu
wrote:
This has been discussed to death a number of times. A field
access obj.field will use addressing with a constant offset. If
that offset is larger than the lowest address allowed to the
application, unsafety may occur.
pointer or
reference, but it's not unsafe, because it can't access _any_ memory,
let
alone memory that it's not supposed to be accessing, which is
precisely what
@safe is all about.
This has been discussed to death a number of times. A field access
obj.field
will use addressing with a
ecause it can't access _any_ memory, let
alone memory that it's not supposed to be accessing, which is precisely what
@safe is all about.
This has been discussed to death a number of times. A field access obj.field
will use addressing with a constant offset. If that offset is large
ereference a null pointer or
reference, but it's not unsafe, because it can't access _any_ memory, let
alone memory that it's not supposed to be accessing, which is precisely what
@safe is all about.
This has been discussed to death a number of times. A field access
obj.field w
On Saturday, February 01, 2014 04:01:50 deadalnix wrote:
> > There's nothing unsafe about null pointers/references. @safe is
> > about memory
> > safety, and you can't corrupt memory and otherwise access
> > memory that you're
> > not supposed to with
On 1/31/14, 5:39 PM, Jonathan M Davis wrote:
Regardless, we're not adding anything with regards to non-nullable references
to the language itself [...]
I think the sea is changing here. I've collected hard data that reveals
null pointer dereference is a top problem for at least certain importa
ay be somewhat of a
compromise. As you've gathered by now, it's simply to disallow
nullifying references in safe code.
The idea is simply that safe functions can only call other safe
functions, so null references should be practically non-existant ...
except that's an ideal which can&#x
901 - 1000 of 1631 matches
Mail list logo
