Lutger:
> First, there is a huge demand for programmers, so much that even I got hired
> in this time of crisis ;) Good programmers don't suddenly fall from the
> skies apparently.
This is the nicest thing I've read this week. Thank you very much :-)
Biologists aren't that lucky, apparently.
On 27-9-2009 9:20, Walter Bright wrote:
language_fan wrote:
The idea behind non-nullable types and other contracts is to catch
these errors on compile time. Sure, the code is a bit harder to write,
but it is safe and never segfaults. The idea is to minimize the amount
of runtime errors of all so
grauzone, el 27 de septiembre a las 22:31 me escribiste:
> >>Woah, nice. I stand corrected. Is this in druntime already?
> >
> >Not yet, its part of a custom runtime I'm working on and wish to
> >release under a public domain license when I get the time. The
> >code is linked from a thread in D.ann
Michel Fortin wrote:
On 2009-09-27 09:41:03 -0400, Andrei Alexandrescu
said:
Michel Fortin wrote:
On 2009-09-26 23:28:30 -0400, Michel Fortin
said:
On 2009-09-26 22:07:00 -0400, Walter Bright
said:
[...] The facilities in D enable one to construct a non-nullable
type, and they are ap
On Fri, 25 Sep 2009 16:49:27 -0400, Andrei Alexandrescu
wrote:
This leads to the interesting setup in which an interface should ideally
define some signatures of to-be-defined functions, but disallow client
code from calling them. For the clients, the same interface should
expose some hi
BCS:
> But this still assumes some degree of reliability of the code doing the fuzzy
> logic.
Fuzzy logic can also be "run" by hardware, fuzzy logic engine chips. Such chips
are usually cheap. You can find them in some consumer products.
The fuzzy logic rules can also be converted to correct p
Andrei Alexandrescu wrote:
Jeremie Pelletier wrote:
Is this Linux specific? what about other *nix systems, like BSD and
solaris?
Signal handler are standard to most *nix platforms since they're part
of the posix C standard libraries, maybe some platforms will require a
special handling but n
I think this is great, especially fine to see final methods in interfaces.
Looks a bit like aspect oriented programming.
Just wanted to add that it's not always *only* a benefit. Like with template
method, flow of control may be a bit more complicated for the people who do
the overriding. But t
Jarrett Billingsley:
> And if you have a nullable reference that you know is not null for the
> rest of the function? Just put "assert(x !is null)" and everything
> that follows will assume it's not null.
Asserts tend to vanish in release mode, so it may be better to use something
different. A p
On 2009-09-27 09:41:03 -0400, Andrei Alexandrescu
said:
Michel Fortin wrote:
On 2009-09-26 23:28:30 -0400, Michel Fortin said:
On 2009-09-26 22:07:00 -0400, Walter Bright said:
[...] The facilities in D enable one to construct a non-nullable type,
and they are appropriate for many desig
Hello Lutger,
BCS wrote:
Hello Lutger,
The answer may
depend on [...]
the habits of the 'programmers' in question, I don't know.
If you can't trust the programmer to write good code, replace them
with someone you can trust. There will never be a usable language
that can take in garbage and
On 2009-09-27 09:53:12 -0400, Andrei Alexandrescu
said:
Then your examples should have shown this instead.
Herb's article has them!
From what I read, Herb's article is focussing on making classes ABI
less fragile by removing virtual functions from public view and forcing
users to call th
Andrei Alexandrescu wrote:
Do you know of a precedent for this? One thing that NVI has going for it
is that it's quite established - it seems to be solidly planted in
programmers' lore. I was surprised to find 2.8M Google matches for the
exact string "Non-Virtual Interface".
Looks like it's c
Jeremie Pelletier wrote:
Is this Linux specific? what about other *nix systems, like BSD and
solaris?
Signal handler are standard to most *nix platforms since they're part of
the posix C standard libraries, maybe some platforms will require a
special handling but nothing impossible to do.
L
Jeremie Pelletier wrote:
downs wrote:
Jeremie Pelletier wrote:
Andrei Alexandrescu wrote:
downs wrote:
Walter Bright wrote:
Nick Sabalausky wrote:
I agree with you that if the compiler can detect null dereferences at
compile time, it should.
Also, by "safe" I presume you mean "memory safe
BCS wrote:
> Hello Lutger,
>
>> The answer may
>> depend on [...]
>> the habits of the 'programmers' in question, I don't know.
>>
>
> If you can't trust the programmer to write good code, replace them with
> someone you can trust. There will never be a usable language that can take
> in garbag
downs wrote:
Jeremie Pelletier wrote:
Andrei Alexandrescu wrote:
downs wrote:
Walter Bright wrote:
Nick Sabalausky wrote:
I agree with you that if the compiler can detect null dereferences at
compile time, it should.
Also, by "safe" I presume you mean "memory safe" which means free of
mem
Jeremie Pelletier wrote:
> grauzone wrote:
>> Andrei Alexandrescu wrote:
>>> Here's an article about the perils of equals in Java (opEquals in D):
>>>
>>> http://www.ddj.com/article/printableArticle.jhtml;jsessionid=GFKUCQH5S4IHNQE1GHOSKHWATMY32JVN?articleID=184405053&dept_url=/java/
>>>
>>>
>>> It
Jeremie Pelletier wrote:
> downs wrote:
>> Jeremie Pelletier wrote:
>>> Christopher Wright wrote:
Jeremie Pelletier wrote:
> What if using 'Object obj;' raises a warning "unitialized variable"
> and makes everyone wanting non-null references happy, and 'Object obj
> = null;' raises
Jeremie Pelletier wrote:
> Andrei Alexandrescu wrote:
>> downs wrote:
>>> Walter Bright wrote:
Nick Sabalausky wrote:
I agree with you that if the compiler can detect null dereferences at
compile time, it should.
>> Also, by "safe" I presume you mean "memory safe"
Hello bearophile,
Do you know fuzzy logic? One of the purposes of fuzzy logic is to
design control systems (that can be used for washing machines,
cameras, missiles, etc) that work and fail gracefully. They don't work
in two binary ways perfect/totallywrong. A graceful failure may have
avoided t
On Sun, Sep 27, 2009 at 3:42 PM, Jeremie Pelletier wrote:
> Jarrett Billingsley wrote:
>> Nonnull types do not create implicit null checks. Nonnull types DO NOT
>> need to be checked. And nullable types WOULD force explicit null
>> checks.
>
> Forcing checks on nullables is just as bad, not all nu
bearophile wrote:
Jeremie Pelletier:
The focus should be
about implementing variable initialization checks to the compiler, since
this solves the issue with any variable, not just references. The flow
analysis can also be reused for many other optimizations.
Are you willing to give your hel
Hello Walter,
Jeremie Pelletier wrote:
It could even be used for any type, the default initializer in D is a
cute idea, but not a performance friendly one. I would much prefer
the compiler to allow "int a" but warn me if I use it before
assigning anything to it than assigning it to zero, and t
Jarrett Billingsley wrote:
On Sun, Sep 27, 2009 at 2:07 PM, Jeremie Pelletier wrote:
Yes and no. It introduces an "if" statement for null checking, but only
for nullable references. If you know your reference can't be null it should
be non-nullable, and then you don't need to check.
I much pr
Hello Lutger,
The answer may
depend on [...]
the habits of the 'programmers' in question, I don't know.
If you can't trust the programmer to write good code, replace them with someone
you can trust. There will never be a usable language that can take in garbage
and spit out correct programs
Yigal Chripun wrote:
On 27/09/2009 19:29, Jeremie Pelletier wrote:
Andrei Alexandrescu wrote:
downs wrote:
Walter Bright wrote:
Nick Sabalausky wrote:
I agree with you that if the compiler can detect null dereferences at
compile time, it should.
Also, by "safe" I presume you mean "memory
Jeremie Pelletier:
> The focus should be
> about implementing variable initialization checks to the compiler, since
> this solves the issue with any variable, not just references. The flow
> analysis can also be reused for many other optimizations.
Are you willing to give your help to implemen
Rainer Deyke:
> Of course, a good optimizer can still reorder the declarations in this
> case, or even eliminate the whole function body (since it doesn't do
> anything).
LLVM has a good optimizer. If you try the LLVM demo on C code with LTO
activated:
http://llvm.org/demo/index.cgi
This C code
Jesse Phillips wrote:
> The thing is that memory safety is the only safety with code.
That is such bullshit. For example, this:
class A {
}
class B {
}
A x = new B;
No memory access violation (yet). Clearly incorrect. Detecting this at
compile time is clearly a safety feature, and
Jeremie Pelletier wrote:
> Walter Bright wrote:
>> They are completely independent variables. One may get assigned to a
>> register, and not the other.
>
> Ok, that's what I thought, so the good old C way of declaring variables
> at the top is not a bad thing yet :)
Strange how you can look at th
Walter Bright wrote:
>> void bar(bool foo) {
>> int a = void;
>> if (foo) {
>> a = 1;
>> } else {
>> a = 2; // Reuse variable.
>> }
>> int c = 3;
>> }
>>
>> You now only have two variables, but both of them coexist at the end of
>> the function. Unless the compi
On 27/09/2009 19:29, Jeremie Pelletier wrote:
Andrei Alexandrescu wrote:
downs wrote:
Walter Bright wrote:
Nick Sabalausky wrote:
I agree with you that if the compiler can detect null dereferences at
compile time, it should.
Also, by "safe" I presume you mean "memory safe" which means free
On Sun, Sep 27, 2009 at 2:07 PM, Jeremie Pelletier wrote:
>> Yes and no. It introduces an "if" statement for null checking, but only
>> for nullable references. If you know your reference can't be null it should
>> be non-nullable, and then you don't need to check.
>
> I much prefer explicit null
On 27/09/2009 19:01, Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
Here's an article about the perils of equals in Java (opEquals in D):
http://www.ddj.com/article/printableArticle.jhtml;jsessionid=GFKUCQH5S4IHNQE1GHOSKHWATMY32JVN?articleID=184405053&dept_url=/java/
I
grauzone wrote:
Andrei Alexandrescu wrote:
Here's an article about the perils of equals in Java (opEquals in D):
http://www.ddj.com/article/printableArticle.jhtml;jsessionid=GFKUCQH5S4IHNQE1GHOSKHWATMY32JVN?articleID=184405053&dept_url=/java/
It turns out this is a great example for NVI. In
Rainer Deyke wrote:
OT, but declaring the variable at the top of the function increases
stack size.
Example with changed variable names:
void bar(bool foo) {
if (foo) {
int a = 1;
} else {
int b = 2;
}
int c = 3;
}
In this example, there are clearly three differ
Michel Fortin wrote:
On 2009-09-27 07:38:59 -0400, Christopher Wright said:
I dislike these forced checks.
Let's say you're dealing with a compiler frontend. You have a semantic
node that just went through some semantic pass and is guaranteed, by
flow control and contracts, to have a certai
language_fan wrote:
Sun, 27 Sep 2009 12:35:23 -0400, Jeremie Pelletier thusly wrote:
language_fan wrote:
Sun, 27 Sep 2009 00:08:50 -0400, Jeremie Pelletier thusly wrote:
Ary Borenszweig wrote:
Just out of curiosity: have you ever programmed in Java or C#?
Nope, never got interested in thes
Walter Bright:
> I've never seen any suggestion that Boeing (or Airbus, or the FAA) has
> changed its philosophy on this. Do you have a reference?
I like to read many books, I have read about this in the chapter Cofee cups in
the piloting room, in the book "Turn Signals Are The Facial Expressio
Sun, 27 Sep 2009 12:35:23 -0400, Jeremie Pelletier thusly wrote:
> language_fan wrote:
>> Sun, 27 Sep 2009 00:08:50 -0400, Jeremie Pelletier thusly wrote:
>>
>>> Ary Borenszweig wrote:
Just out of curiosity: have you ever programmed in Java or C#?
>>> Nope, never got interested in these to t
Jesse Phillips:
>The thing is that memory safety is the only safety with code.<
Nope. For example in Delphi and C# you can have a runtime integer overflow
errors. That's another kind of safety.
If you look at safety-critical code, the one Walter was talking about, you see
people test code (and
Andrei Alexandrescu wrote:
downs wrote:
Walter Bright wrote:
Nick Sabalausky wrote:
I agree with you that if the compiler can detect null dereferences at
compile time, it should.
Also, by "safe" I presume you mean "memory safe" which means free of
memory corruption. Null pointer exceptions
Hello Walter,
The only reasonable thing a program can do if it discovers it is in an
unknown state is to stop immediately.
This whole thread is NOT about what to do on unknown states. It is about
using the compiler to statically remove the possibility of one type of unknown
state ever happe
grauzone wrote:
Andrei Alexandrescu wrote:
Here's an article about the perils of equals in Java (opEquals in D):
http://www.ddj.com/article/printableArticle.jhtml;jsessionid=GFKUCQH5S4IHNQE1GHOSKHWATMY32JVN?articleID=184405053&dept_url=/java/
It turns out this is a great example for NVI. In
On Sun, 27 Sep 2009 11:51:27 -0400, bearophile
wrote:
Steven Schveighoffer:
Build the non-null requirement into the function signature (note, the
requirement is optional, it's still possible to use null references if
you
want).
Pros: Easy to implement, Compile-time error, hard to
Sun, 27 Sep 2009 16:47:51 +, Jesse Phillips thusly wrote:
> The thing is that memory safety is the only safety with code. In
> Walter's examples he very clearly showed that a crash is not unsafe, but
> operating with incorrect values is. He has pointed out that if
> initialization is enforced,
Andrei Alexandrescu wrote:
Here's an article about the perils of equals in Java (opEquals in D):
http://www.ddj.com/article/printableArticle.jhtml;jsessionid=GFKUCQH5S4IHNQE1GHOSKHWATMY32JVN?articleID=184405053&dept_url=/java/
It turns out this is a great example for NVI. In D, we could and
Walter Bright wrote:
Andrei Alexandrescu wrote:
This feature would require changing some protection rules, I think for
the better. What do you think?
1. what are those changes?
I thought some more about it and here are the changes in protection rules:
1. Public final methods CANNOT be hijac
BCS wrote:
Hello Walter,
Andrei Alexandrescu wrote:
Second, the new rule is simple: if the overriding function can be
called with the overriden function's arguments, it is overriding it.
True, things get more complicated when the base class also defines a
corresponding overload:
class A {
vo
On Sun, 27 Sep 2009 10:10:19 -0400, Nick Sabalausky wrote:
> "Walter Bright" wrote in message
> news:h9n3k5$2eu...@digitalmars.com...
>> Jason House wrote:
Also, by "safe" I presume you mean "memory safe" which means free of
memory corruption. Null pointer exceptions are memory safe. A
Hello downs,
PS: You can't convert segfaults into exceptions under Linux, as far as
I know.
Last I checked, throwing from a signal handler works on linux.
Hello Walter,
Andrei Alexandrescu wrote:
Second, the new rule is simple: if the overriding function can be
called with the overriden function's arguments, it is overriding it.
True, things get more complicated when the base class also defines a
corresponding overload:
class A {
void fun(A);
v
Jérôme M. Berger wrote:
Michel Fortin wrote:
I fully support having a way to specify a default implementation for a
function in an interface. It might get handy for a few things (like
implementing the delegate pattern you see everywhere in Cocoa). But
it's a bad replacement for contracts.
language_fan wrote:
Sun, 27 Sep 2009 00:08:50 -0400, Jeremie Pelletier thusly wrote:
Ary Borenszweig wrote:
Just out of curiosity: have you ever programmed in Java or C#?
Nope, never got interested in these to tell the truth. I only did C,
C++, D and x86 assembly in systems programming, I hav
Here's an article about the perils of equals in Java (opEquals in D):
http://www.ddj.com/article/printableArticle.jhtml;jsessionid=GFKUCQH5S4IHNQE1GHOSKHWATMY32JVN?articleID=184405053&dept_url=/java/
It turns out this is a great example for NVI. In D, we could and should
do the following:
class
On 27/09/2009 17:51, bearophile wrote:
Steven Schveighoffer:
Build the non-null requirement into the function signature (note,
the requirement is optional, it's still possible to use null
references if you want).
Pros: Easy to implement, Compile-time error, hard to "work around"
by putting a d
Here's an article about the perils of equals in Java (opEquals in D):
http://www.ddj.com/article/printableArticle.jhtml;jsessionid=GFKUCQH5S4IHNQE1GHOSKHWATMY32JVN?articleID=184405053&dept_url=/java/
It turns out this is a great example for NVI. In D, we could and should
do the following:
cla
downs wrote:
Jeremie Pelletier wrote:
Christopher Wright wrote:
Jeremie Pelletier wrote:
What if using 'Object obj;' raises a warning "unitialized variable"
and makes everyone wanting non-null references happy, and 'Object obj
= null;' raises no warning and makes everyone wanting to keep the
c
Walter Bright wrote:
Jeremie Pelletier wrote:
This may be a good time to ask about how these variables which can be
declared anywhere in the function scope are implemented.
void bar(bool foo) {
if(foo) {
int a = 1;
...
}
else {
int a = 2;
...
}
Andrei Alexandrescu wrote:
Frank Benoit wrote:
Andrei Alexandrescu schrieb:
Frank Benoit wrote:
Andrei Alexandrescu schrieb:
Consider two objects a and b with a of class type. Currently, the
expression a == b is blindly rewritten as a.opEquals(b). I argue it
should be rewritten into a call to
Steven Schveighoffer:
>Build the non-null requirement into the function signature (note, the
> requirement is optional, it's still possible to use null references if you
> want).
>
>Pros: Easy to implement, Compile-time error, hard to "work around" by
> putting a dummy value, someti
Lutger Wrote:
> This is what it's about, I think: are non-nullable references *by default*
> so annoying as to cause programmers to initialize them with wrong values (or
> circumventing them in other ways)?
> The answer may depend on the details of the feature, quality of
> implementation and
On Sat, 26 Sep 2009 17:08:32 -0400, Walter Bright
wrote:
Denis Koroskin wrote:
> On Sat, 26 Sep 2009 22:30:58 +0400, Walter Bright
> wrote:
>> D has borrowed ideas from many different languages. The trick is to
>> take the good stuff and avoid their mistakes .
>
> How about this one:
Robert Jacques wrote:
On Sun, 27 Sep 2009 09:11:38 -0400, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
On Sat, 26 Sep 2009 21:32:13 -0400, Andrei Alexandrescu
wrote:
Consider two objects a and b with a of class type. Currently, the
expression a == b is blindly rewritten as a.opEquals
On Sun, 27 Sep 2009 09:11:38 -0400, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
On Sat, 26 Sep 2009 21:32:13 -0400, Andrei Alexandrescu
wrote:
Consider two objects a and b with a of class type. Currently, the
expression a == b is blindly rewritten as a.opEquals(b). I argue it
sh
Michel Fortin wrote:
I fully support having a way to specify a default implementation for a
function in an interface. It might get handy for a few things (like
implementing the delegate pattern you see everywhere in Cocoa). But it's
a bad replacement for contracts.
Then what's the difference
On Sun, 27 Sep 2009 10:32:29 -0400, Andrei Alexandrescu
wrote:
Frank Benoit wrote:
Andrei Alexandrescu schrieb:
Frank Benoit wrote:
Andrei Alexandrescu schrieb:
Consider two objects a and b with a of class type. Currently, the
expression a == b is blindly rewritten as a.opEquals(b). I arg
Andrei Alexandrescu schrieb:
> Frank Benoit wrote:
>> In DWT, I cast always first to Object.
>> Java> if( intf1.equals(intf2) ){
>> D1.0> if( ((cast(Object)intf1).opEquals( cast(Object)intf2 )){
>
> I think in D the cast is inserted automatically. Walter?
>
> Andrei
there is a related bug report
Nick Sabalausky wrote:
> "Walter Bright" wrote in message
...
> You're acting as if handling failures safely and minimizing failures were
> mutually exclusive.
Not that I have an opinion on this either way, but if I understand Walter
right that is exactly his point (although you exaggerate it a
"Walter Bright" wrote in message
news:h9n44k$2g6...@digitalmars.com...
>
> Memory safety is something that can be guaranteed (presuming the compiler
> is correctly implemented). There is no way to guarantee that a non-trivial
> program cannot crash. It's the old halting problem.
>
No one said
Frank Benoit wrote:
Andrei Alexandrescu schrieb:
Frank Benoit wrote:
Andrei Alexandrescu schrieb:
Consider two objects a and b with a of class type. Currently, the
expression a == b is blindly rewritten as a.opEquals(b). I argue it
should be rewritten into a call to an (imaginary/inlined) func
Nick Sabalausky:
> He keeps saying "safe", and every time he does you turn it into "memory
> safe". If he meant "memory safe" he probably would have said something like
> "memory safe". He already made it perfectly clear he's talking about
> crashes, so continuing to put the words "memory safe"
Andrei Alexandrescu schrieb:
> Frank Benoit wrote:
>> Andrei Alexandrescu schrieb:
>>> Consider two objects a and b with a of class type. Currently, the
>>> expression a == b is blindly rewritten as a.opEquals(b). I argue it
>>> should be rewritten into a call to an (imaginary/inlined) function
>>>
"Walter Bright" wrote in message
news:h9n3k5$2eu...@digitalmars.com...
> Jason House wrote:
>>> Also, by "safe" I presume you mean "memory safe" which means free
>>> of memory corruption. Null pointer exceptions are memory safe. A
>>> null pointer could be caused by memory corruption, but it cann
Andrei Alexandrescu:
> One good thing about nullable references
> is that they are dynamically checked for validity at virtually zero
> cost. Non-nullable references, therefore, would not add value in that
> respect, but would add value by reducing the cases when programmers
> forgot to initia
Michel Fortin wrote:
On 2009-09-26 10:06:24 -0400, Andrei Alexandrescu
said:
Michel Fortin wrote:
I think you're writing a lot of boilerplate code for something that
the compiler should be able to do by itself. I mean, it's a lot
cleaner with contracts, and there is no reason the compiler c
downs wrote:
Walter Bright wrote:
Nick Sabalausky wrote:
I agree with you that if the compiler can detect null dereferences at
compile time, it should.
Also, by "safe" I presume you mean "memory safe" which means free of
memory corruption. Null pointer exceptions are memory safe. A null
poin
Frank Benoit wrote:
Andrei Alexandrescu schrieb:
Consider two objects a and b with a of class type. Currently, the
expression a == b is blindly rewritten as a.opEquals(b). I argue it
should be rewritten into a call to an (imaginary/inlined) function
equalObjects(a, b), with the following definit
Michel Fortin wrote:
On 2009-09-26 23:28:30 -0400, Michel Fortin
said:
On 2009-09-26 22:07:00 -0400, Walter Bright
said:
[...] The facilities in D enable one to construct a non-nullable
type, and they are appropriate for many designs. I just don't see
them as a replacement for *all* refe
Walter Bright wrote:
Andrei Alexandrescu wrote:
Walter Bright wrote:
Justin Johansson wrote:
Walter, in the heat of this thread I hope you haven't missed the
correlation with discussion
on "Dispatching on a variant" and noting:
Thanks for pointing it out. The facilities in D enable one to
Jeremie Pelletier wrote:
Walter Bright wrote:
Yigal Chripun wrote:
An exception trace is *far* better than a segfault and that does not
require null values.
Seg faults are exceptions, too. You can even catch them (on windows)!
Walter, check the crash handler I submitted to D.announce, it ha
Robert Jacques wrote:
On Sat, 26 Sep 2009 21:32:13 -0400, Andrei Alexandrescu
wrote:
Consider two objects a and b with a of class type. Currently, the
expression a == b is blindly rewritten as a.opEquals(b). I argue it
should be rewritten into a call to an (imaginary/inlined) function
equal
On 2009-09-26 10:06:24 -0400, Andrei Alexandrescu
said:
Michel Fortin wrote:
I think you're writing a lot of boilerplate code for something that the
compiler should be able to do by itself. I mean, it's a lot cleaner
with contracts, and there is no reason the compiler couldn't generate
itse
downs:
> Basically, anything that may fill it with nulls.
>
> The only two allowed instructions would be ~= NonNullable and ~=
> NonNullableArray. And it's good that way.
I agree.
In such situation I'd also like to have a default method to insert one or more
nonnull items in any point of the a
Jarrett Billingsley wrote:
On Sat, Sep 26, 2009 at 9:32 PM, Andrei Alexandrescu
wrote:
Consider two objects a and b with a of class type. Currently, the expression
a == b is blindly rewritten as a.opEquals(b). I argue it should be rewritten
into a call to an (imaginary/inlined) function equalOb
On 2009-09-27 07:38:59 -0400, Christopher Wright said:
I dislike these forced checks.
Let's say you're dealing with a compiler frontend. You have a semantic
node that just went through some semantic pass and is guaranteed, by
flow control and contracts, to have a certain property initialized
Walter Bright wrote:
> Name any single part or system on a Boeing airliner, and if it
> vanishes abruptly in a puff of smoke, the airliner will survive it.
Except this sentence I applaud every thought.
If "single part" includes the passenger area, the meaning of this sentence
is upright ridicu
Michel Fortin wrote:
On 2009-09-26 22:07:00 -0400, Walter Bright
said:
[...] The facilities in D enable one to construct a non-nullable type,
and they are appropriate for many designs. I just don't see them as a
replacement for *all* reference types.
As far as I understand this thread, no
Andrei Alexandrescu wrote:
Walter Bright wrote:
Justin Johansson wrote:
Walter, in the heat of this thread I hope you haven't missed the
correlation with discussion
on "Dispatching on a variant" and noting:
Thanks for pointing it out. The facilities in D enable one to
construct a non-nullab
Jeremie Pelletier wrote:
There again, I favor stronger initialization semantics over nonnull
types. This will get rid of most of these errors
Only for local variables. Not for fields.
Most segfaults I have take me at most a few minutes to pinpoint. Its
finding backdoors to compiler enforcemen
Walter Bright wrote:
Andrei Alexandrescu wrote:
Walter Bright wrote:
Even forcing an explicit initializer doesn't actually solve the
problem - my experience with such features is programmers simply
insert any old value to get the code to pass the compiler, even
programmers who know it's a bad
Sun, 27 Sep 2009 00:27:14 -0700, Walter Bright thusly wrote:
>> You seem to be under the impression that nothing can be made
>> uncrashable without introducing the possibility of corrupted state.
>> That's hogwash.
What I mean by safe is that no matter what you do, you cannot make the
program cr
Jeremie Pelletier wrote:
> Christopher Wright wrote:
>> Jeremie Pelletier wrote:
>>> What if using 'Object obj;' raises a warning "unitialized variable"
>>> and makes everyone wanting non-null references happy, and 'Object obj
>>> = null;' raises no warning and makes everyone wanting to keep the
>>
Jeremie Pelletier wrote:
> Jarrett Billingsley wrote:
>> On Sat, Sep 26, 2009 at 11:23 PM, Jeremie Pelletier
>> wrote:
>>
>>> There is no such thing as "not being able to happen" :)
>>>
>>> Object thisCannotPossiblyBeNullInAnyWayWhatsoever = cast(Object)null;
>>>
>>> I seem to be the only one who
Denis Koroskin wrote:
> On Sun, 27 Sep 2009 03:01:48 +0400, Walter Bright
> wrote:
>
>> Denis Koroskin wrote:
>>> One more:
>>> T foo(bool someCondition)
>>> {
>>> T? t;
>>> if (someCondition) t = someInitializer();
>>> // ...
>>> if (t.isNull) { // not initialized yet
>>>
Sun, 27 Sep 2009 00:08:50 -0400, Jeremie Pelletier thusly wrote:
> Ary Borenszweig wrote:
>> Just out of curiosity: have you ever programmed in Java or C#?
>
> Nope, never got interested in these to tell the truth. I only did C,
> C++, D and x86 assembly in systems programming, I have quite a
> b
Walter Bright wrote:
> Nick Sabalausky wrote:
>
> I agree with you that if the compiler can detect null dereferences at
> compile time, it should.
>
>
>>> Also, by "safe" I presume you mean "memory safe" which means free of
>>> memory corruption. Null pointer exceptions are memory safe. A null
>
Jeremie Pelletier wrote:
> void bar(bool foo) {
> if(foo) {
> int a = 1;
> ...
> }
> else {
> int a = 2;
> ...
> }
>
> }
>
> is the stack frame using two ints, or is the compiler seeing only one? I
> never bothered to check it out and just declared
Jeremie Pelletier wrote:
This may be a good time to ask about how these variables which can be
declared anywhere in the function scope are implemented.
void bar(bool foo) {
if(foo) {
int a = 1;
...
}
else {
int a = 2;
...
}
}
is the stack frame
1 - 100 of 107 matches
Mail list logo
