On 27/11/2010 03:29, Rainer Deyke wrote:
On 11/26/2010 10:28, Bruno Medeiros wrote:
Yes, Walter's statement that it is impossible for a null pointer to
cause a security vulnerability is (likely) incorrect.
But his point at large, considering the discussion that preceded the
comment, was that nul
On 26/11/2010 19:20, Daniel Gibson wrote:
So, going back, is it correct to say that an NPE bug on its own is not
enough to allow arbitrary code execution, but that other
vulnerabilities are necessary?
I don't think it's correct: You may have a "bad" user on your system
(e.g. pseudo-public ser
On 26/11/2010 17:54, Bruno Medeiros wrote:
On 26/11/2010 17:28, Bruno Medeiros wrote:
And I agree with that, and because of that I'm suprised and curious to
understand why Hoare mentioned (in the abstract on the link posted
originally), that null pointers have caused "innumerable vulnerabilitie
Daniel Gibson Wrote:
> Rainer Deyke schrieb:
> > On 11/26/2010 10:28, Bruno Medeiros wrote:
> >> Yes, Walter's statement that it is impossible for a null pointer to
> >> cause a security vulnerability is (likely) incorrect.
> >> But his point at large, considering the discussion that preceded the
Rainer Deyke schrieb:
On 11/26/2010 10:28, Bruno Medeiros wrote:
Yes, Walter's statement that it is impossible for a null pointer to
cause a security vulnerability is (likely) incorrect.
But his point at large, considering the discussion that preceded the
comment, was that null pointers are utte
On 11/26/2010 10:28, Bruno Medeiros wrote:
> Yes, Walter's statement that it is impossible for a null pointer to
> cause a security vulnerability is (likely) incorrect.
> But his point at large, considering the discussion that preceded the
> comment, was that null pointers are utterly insignificant
Bruno Medeiros schrieb:
On 25/11/2010 16:55, Daniel Gibson wrote:
On Thu, Nov 25, 2010 at 5:28 PM, Bruno Medeiros
wrote:
On 05/11/2010 18:52, Daniel Gibson wrote:
Walter Bright schrieb:
It's infinitely worse. Null pointers do not result in memory
corruption, buffer overflows, and securit
On 26/11/2010 17:28, Bruno Medeiros wrote:
And I agree with that, and because of that I'm suprised and curious to
understand why Hoare mentioned (in the abstract on the link posted
originally), that null pointers have caused "innumerable vulnerabilities.
Hum, cool, I just found out that this l
On 06/11/2010 20:02, Walter Bright wrote:
Jérôme M. Berger wrote:
I thought D was supposed to be a pragmatic language? All this means
is that we need a compromise between what would be ideal (being able
to represent arbitrary conditions and have them statically enforced
at compile time) and what
On 25/11/2010 16:55, Daniel Gibson wrote:
On Thu, Nov 25, 2010 at 5:28 PM, Bruno Medeiros
wrote:
On 05/11/2010 18:52, Daniel Gibson wrote:
Walter Bright schrieb:
It's infinitely worse. Null pointers do not result in memory
corruption, buffer overflows, and security breaches.
Not entire
On 06/11/2010 19:57, Walter Bright wrote:
Adam Burton wrote:
I wouldn't consider that as the same thing. null represents the lack
of a value where as 25 is the wrong value. Based on that argument the
application should fail immediately on accessing the item with 25 (not
many moons later) in the
On Thu, 25 Nov 2010 10:54:39 -0600
Ellery Newcomer wrote:
> From a language designer's perspective, I think programmer association
> of semantic meaning to null (along with null's weak typing) is a more
> serious problem than npe vulnerabilities.
True! An unfortunately rarely pointed issue and
On 05/11/2010 18:52, Walter Bright wrote:
I think you misunderstand why checked exceptions are such a bad idea.
It's not just that they are inconvenient and annoying. They decrease
security by *hiding* bugs. That is the opposite of what you'd want in a
high security language.
http://www.mindvie
On Thu, Nov 25, 2010 at 5:28 PM, Bruno Medeiros
wrote:
> On 05/11/2010 18:52, Daniel Gibson wrote:
>>
>> Walter Bright schrieb:
>>>
>>> bearophile wrote:
Walter Bright:
> The $10 billion mistake was C's conversion of arrays to pointers when
> passing to a function.
>
>>>
On 11/25/2010 10:28 AM, Bruno Medeiros wrote:
I think Walter's point remains true: null pointers bugs are an order of
magnitude less important, if not downright insignificant, with regards
to security breaches.
I mean, from my understanding of that article, a NPE bug on its own is
not enough to
On 05/11/2010 18:52, Daniel Gibson wrote:
Walter Bright schrieb:
bearophile wrote:
Walter Bright:
The $10 billion mistake was C's conversion of arrays to pointers when
passing to a function.
http://www.drdobbs.com/blog/archives/2009/12/cs_biggest_mist.html
Sadly, there's an ongoing failure
Kagamin schrieb:
FeepingCreature Wrote:
This means stack traces are out unless you have special handling for segfaults
that decodes the stack and prints the error pos. That in turn means you need to
have a debugger attached to get stacktraces, which can be annoying especially
in long-running
FeepingCreature Wrote:
> This means stack traces are out unless you have special handling for
> segfaults that decodes the stack and prints the error pos. That in turn means
> you need to have a debugger attached to get stacktraces, which can be
> annoying especially in long-running programs wh
Hah people bringing up the argument "bad syntax", when they got nothing to
say!
Like they type "Matrix!(double, 5, 5)" every time they use a matrix
no you never do that, you just:
alias Matrix!(double, 5, 5) mat5; // sweet isn't it? Remember! it is a
type!
On Sat, 06 Nov 2010 12:27:34 +0200,
Walter Bright Wrote:
> FeepingCreature wrote:
> > Walter Bright Wrote:
> >
> >> FeepingCreature wrote:
> >>> Walter Bright Wrote:
> All that does is reinvent the null pointer seg fault. The hardware does
> this for you for free.
> >>> Walter, I know you're a Windows programmer but this
bearophile wrote:
Concurrency bugs are far harder to fix (or even to find) than
null pointer exceptions. This thread is not about ways to avoid concurrency
bugs
The hardest problems are concurrency issues, followed by memory corruption.
On Sat, 06 Nov 2010 23:37:09 +0300, Gary Whatmore wrote:
Walter Bright Wrote:
Adam Burton wrote:
> I wouldn't consider that as the same thing. null represents the lack
of a
> value where as 25 is the wrong value. Based on that argument the
application
> should fail immediately on accessin
On Sun, 07 Nov 2010 00:58:57 +0300, Walter Bright
wrote:
FeepingCreature wrote:
Walter Bright Wrote:
FeepingCreature wrote:
Walter Bright Wrote:
All that does is reinvent the null pointer seg fault. The hardware
does
this for you for free.
Walter, I know you're a Windows programmer bu
Walter Bright wrote:
>
> Very, very few (if any) dmd issues on bugzilla would have been caught by
> ranged integers or non-null pointers (despite there being several seg
> fault bugs).
>
> The vast majority of the problems were the result of an incomplete
> understanding of how things should be d
bearophile wrote:
Walter Bright:
Adding ranged integer types increases the coverage from 1% to 2% of the
cases. (Pulling random numbers out of the ether, but still, I think the
point is valid.)
I don't know if that point is valid. SPARK language is able to have a
testable low bug count, and i
Walter Bright:
> Adding ranged integer types increases the coverage from 1% to 2% of the
> cases.
> (Pulling random numbers out of the ether, but still, I think the point is
> valid.)
I don't know if that point is valid. SPARK language is able to have a testable
low bug count, and it only has
Simen kjaeraas:
> 3 Can only be created with a nonzero length with a runtime check of a
>nullable-element array/collection, or as a literal containing only
>non-nullable elements.
> ...
> In many cases, rule #3 will
> allow you to create your collection using nullable elements, and casting
Roman Ivanov wrote:
But it's not a specific case if you look at it from OOP perspective!
The problem of restricting types was solved in OOP. Every time you
inherit a class, you make it more specific. This allows you to restrict
types all you want, and the compiler enforces your restrictions.
Fo
bearophile wrote:
Walter:
Any type having an unexpected value in it is a very common bug. They often
go unnoticed, though, because they don't generate a seg fault. The bug is
still there, though.
So no, I don't agree it is a special case.
Then to D3, beside nonnull types, we may also add ran
Walter:
> Any type having an unexpected value in it is a very common bug. They often go
> unnoticed, though, because they don't generate a seg fault. The bug is still
> there, though.
>
> So no, I don't agree it is a special case.
Then to D3, beside nonnull types, we may also add ranged intege
On 11/6/2010 4:02 PM, Walter Bright wrote:
> Jérôme M. Berger wrote:
>> I thought D was supposed to be a pragmatic language? All this means
>> is that we need a compromise between what would be ideal (being able
>> to represent arbitrary conditions and have them statically enforced
>> at compil
bearophile wrote:
I don't see that non-null is such a special case that it would benefit from a
special case syntax.
Well, nonnull are a special cases because:
- There is a good enough way to solve this problem. This is not true in the
general case.
- null exceptions are very common bugs, amon
Walter Bright wrote:
I don't see that non-null is such a special case that it would benefit
from a special case syntax. For example:
There are some things that set non-null apart:
1. Few operations change the value of a pointer/class reference:
assignment
pointer arithmetic
ref pas
tls wrote:
I never seen segfault in practice. Have you?
Have you ever touched a computer? I see segfaults about daily. In my own
code, not that often.
--
Simen
Gary Whatmore wrote:
non-nulls don't solve basic problems like arrays, basic collections in
the library (custom fill policy).
As I've posted elsewhere, arrays (and other collections) will have to
work slightly differently for non-nullable elements:
1 .length is read-only (or read/decrease on
On 11/6/2010 15:00, Walter Bright wrote:
> I don't see that non-null is such a special case that it would benefit
> from a special case syntax.
I'm less concerned about syntax and more about semantics. I already use
nn_ptr (short for non-null pointer) in C++. It works in C++ because
types in C++
FeepingCreature wrote:
Walter Bright Wrote:
FeepingCreature wrote:
Walter Bright Wrote:
All that does is reinvent the null pointer seg fault. The hardware does
this for you for free.
Walter, I know you're a Windows programmer but this cannot be the first
time somebody has told you this - YO
steveh:
> citation needed. I've made software with 100% line and path coverage. No
> segfaults happened ever. Spent enormous time optimizing the code and its
> quality. In quality applications NPE/segfaults simply don't exist.
You are right, some citation is needed. I have seen or read many pap
Walter Bright Wrote:
> FeepingCreature wrote:
> > Walter Bright Wrote:
> >> All that does is reinvent the null pointer seg fault. The hardware does
> >> this for you for free.
> >
> > Walter, I know you're a Windows programmer but this cannot be the first time
> > somebody has told you this - YOU
Walter Bright wrote:
> Adam Burton wrote:
>> I *think* I undertand what you mean, however I also think I failed to
>> explain myself correctly. After reading bearophiles post I think he put
>> it in much better terms of null being a common case that is handled in
>> common way.
>
> I don't see th
Walter:
> Granted, even 100% coverage is no guarantee of no seg faults, but in practice
> it
> is very effective.
Unittests are widely used in Java, still null exceptions are not uncommon in
Java.
> And finally, null exceptions are not a bug. They are the messenger that there
> is
> a bug
bearophile Wrote:
> Walter:
>
> > I don't see that non-null is such a special case that it would benefit from
> > a
> > special case syntax.
>
> Well, nonnull are a special cases because:
> - There is a good enough way to solve this problem. This is not true in the
> general case.
> - null ex
Walter:
> I don't see that non-null is such a special case that it would benefit from a
> special case syntax.
Well, nonnull are a special cases because:
- There is a good enough way to solve this problem. This is not true in the
general case.
- null exceptions are very common bugs, among the m
bearophile wrote:
Gary Whatmore:
You're missing the point. The reason for seg faults is to terminate the
application as quickly as possible. The developer then fires up the
debugger and fixes the app. Seg faults should never happen in production
code. You only release when all seg faults are fi
Adam Burton wrote:
I *think* I undertand what you mean, however I also think I failed to
explain myself correctly. After reading bearophiles post I think he put it
in much better terms of null being a common case that is handled in common
way.
I don't see that non-null is such a special case
Sat, 06 Nov 2010 21:52:22 +0100, Jérôme M. Berger wrote:
> FeepingCreature wrote:
>> Walter Bright Wrote:
>>> All that does is reinvent the null pointer seg fault. The hardware
>>> does this for you for free.
>>
>> Walter, I know you're a Windows programmer but this cannot be the first
>> time so
> New and much more flexible static type systems are possible, like the SPARK
> and ATS ones, but they require a kind of programming that asks lot of brain
> from the programmer, so they are mostly for special purposes only.
Sorry, unfinished post. I was saying:
Languages like Spec#, Haskell a
Gary Whatmore:
> Doesn't it mean that instead of complicating the language we write more unit
> tests?
This is true, it's a design decision. And we are indeed trying to decide if
this feature is worth it.
A sufficiently large amount of unittests is indeed able to remove and avoid a
large enou
bearophile Wrote:
> Gary Whatmore:
>
> > I'm seeing it. The other arguments for non-null types also fall short
> > because non-nulls don't solve basic problems like arrays, basic collections
> > in the library (custom fill policy).
>
> Arrays and collections are a subset of the nonull problem
FeepingCreature wrote:
> Walter Bright Wrote:
>> All that does is reinvent the null pointer seg fault. The hardware does this
>> for
>> you for free.
>
> Walter, I know you're a Windows programmer but this cannot be the first time
> somebody has told you this - YOU CANNOT RECOVER FROM SEG FAULT
Gary Whatmore:
> I'm seeing it. The other arguments for non-null types also fall short because
> non-nulls don't solve basic problems like arrays, basic collections in the
> library (custom fill policy).
Arrays and collections are a subset of the nonull problem I am discussing
about. I have sh
FeepingCreature wrote:
Walter Bright Wrote:
All that does is reinvent the null pointer seg fault. The hardware does
this for you for free.
Walter, I know you're a Windows programmer but this cannot be the first time
somebody has told you this - YOU CANNOT RECOVER FROM SEG FAULTS UNDER LINUX.
Walter Bright wrote:
> Adam Burton wrote:
>> I wouldn't consider that as the same thing. null represents the lack of a
>> value where as 25 is the wrong value. Based on that argument the
>> application should fail immediately on accessing the item with 25 (not
>> many moons later) in the same mann
bearophile Wrote:
> Gary Whatmore:
>
> > You're missing the point. The reason for seg faults is to terminate the
> > application as quickly as possible. The developer then fires up the
> > debugger and fixes the app. Seg faults should never happen in production
> > code. You only release when
Walter Bright Wrote:
> Adam Burton wrote:
> > I wouldn't consider that as the same thing. null represents the lack of a
> > value where as 25 is the wrong value. Based on that argument the
> > application
> > should fail immediately on accessing the item with 25 (not many moons
> > later)
> >
Gary Whatmore:
> You're missing the point. The reason for seg faults is to terminate the
> application as quickly as possible. The developer then fires up the debugger
> and fixes the app. Seg faults should never happen in production code. You
> only release when all seg faults are fixed. The b
Roman Ivanov Wrote:
> On 11/6/2010 2:14 PM, Walter Bright wrote:
> > Rainer Deyke wrote:
> >> On 11/6/2010 02:42, Walter Bright wrote:
> >>> Adam D. Ruppe wrote:
> It wasn't until I added the invariant and in/out contracts to all the
> functions
> asserting about null that the probl
On 11/6/2010 2:14 PM, Walter Bright wrote:
> Rainer Deyke wrote:
>> On 11/6/2010 02:42, Walter Bright wrote:
>>> Adam D. Ruppe wrote:
It wasn't until I added the invariant and in/out contracts to all the
functions
asserting about null that the problem's true cause became apparent.
>>
FeepingCreature Wrote:
> Walter Bright Wrote:
> > All that does is reinvent the null pointer seg fault. The hardware does
> > this for
> > you for free.
>
> Walter, I know you're a Windows programmer but this cannot be the first time
> somebody has told you this - YOU CANNOT RECOVER FROM SEG F
Walter Bright Wrote:
> All that does is reinvent the null pointer seg fault. The hardware does this
> for
> you for free.
Walter, I know you're a Windows programmer but this cannot be the first time
somebody has told you this - YOU CANNOT RECOVER FROM SEG FAULTS UNDER LINUX.
Access violations
Jérôme M. Berger wrote:
I thought D was supposed to be a pragmatic language? All this means
is that we need a compromise between what would be ideal (being able
to represent arbitrary conditions and have them statically enforced
at compile time) and what can be realistically achieved. You
Adam Burton wrote:
I wouldn't consider that as the same thing. null represents the lack of a
value where as 25 is the wrong value. Based on that argument the application
should fail immediately on accessing the item with 25 (not many moons later)
in the same manner it does nulls, but it doesn't
bearophile Wrote:
> Walter:
>
> > retard wrote:
> > > In a functional language:
> > >
> > > start_the_car c = case c of
> > > Just car -> start car
> > > Nothing -> error "not initialized"
> >
> > And the null pointer exception is reinvented!
>
> That "case" statement (is a pattern matchin
Andrei Alexandrescu:
> To find an array that always has initialized data, look no further than
> std::vector. There is no way to grow an std::vector without filling it
> with data under user's control. The only place where std::vector assumes
> a default is the resize function:
>
> void vector
Walter:
> retard wrote:
> > In a functional language:
> >
> > start_the_car c = case c of
> > Just car -> start car
> > Nothing -> error "not initialized"
>
> And the null pointer exception is reinvented!
That "case" statement (is a pattern matching) forces you to manage the null
case ever
Walter:
> Suppose, for example, you are appending prime numbers to the array, and
> somehow appended a 25. Many moons later, something crashes because the 25 was
> not prime.
There are two main ways to avoid this bug:
- Put some test in the code, such test may be an explicit test at the point
wh
Walter Bright wrote:
> bearophile wrote:
>>> Suppose, for example, you are appending the numbers 1..5 to the
>>> array, and somehow appended a 17. Many moons later, something crashes
>>> because the 17 was out of range.
>>
>> This bug doesn't happen in Ada (and Delphi), because you define a
>> rang
Walter Bright wrote:
> bearophile wrote:
>>> Suppose, for example, you are appending the numbers 1..5 to the array,
>>> and somehow appended a 17. Many moons later, something crashes because
>>> the 17 was out of range.
>>
>> This bug doesn't happen in Ada (and Delphi), because you define a range
On 11/6/2010 02:47, Walter Bright wrote:
> Rainer Deyke wrote:
>> On 11/5/2010 17:41, Walter Bright wrote:
>>> In other words, I create an array that I mean to fill in later, because
>>> I don't have meaningful data for it in advance.
>>
>> That's a faulty idiom. A data structure that exists but c
Sat, 06 Nov 2010 11:24:01 -0700, Walter Bright wrote:
> retard wrote:
>> In a functional language:
>>
>> start_the_car c = case c of
>> Just car -> start car
>> Nothing -> error "not initialized"
>
> And the null pointer exception is reinvented!
What was the point of my post again? To be an
retard wrote:
In a functional language:
start_the_car c = case c of
Just car -> start car
Nothing -> error "not initialized"
And the null pointer exception is reinvented!
Simen kjaeraas wrote:
I believe you managed to miss the important part, "If we could disable the
default constructor".
Yes, I believe you are correct.
Simen kjaeraas wrote:
Bounded!(int, 1, 5)[] myArr;
myArr ~= 1; // Compile-time error: int is not implicitly castable to
Bounded!(int, 1, 5)
myArr ~= Bounded!(int, 1, 5)( 1 ); // Works perfectly
Yes, that's it.
bearophile wrote:
Suppose, for example, you are appending the numbers 1..5 to the array, and
somehow appended a 17. Many moons later, something crashes because the 17 was
out of range.
This bug doesn't happen in Ada (and Delphi), because you define a ranged
integer type like this:
subtype Sma
Rainer Deyke wrote:
On 11/6/2010 02:42, Walter Bright wrote:
Adam D. Ruppe wrote:
It wasn't until I added the invariant and in/out contracts to all the
functions
asserting about null that the problem's true cause became apparent.
Couldn't this happen to you with any datum that has an unexpecte
Walter Bright, el 6 de noviembre a las 01:47 me escribiste:
> Rainer Deyke wrote:
> >On 11/5/2010 17:41, Walter Bright wrote:
> >>In other words, I create an array that I mean to fill in later, because
> >>I don't have meaningful data for it in advance.
> >
> >That's a faulty idiom. A data struct
Walter said:
> Couldn't this happen to you with any datum that has an unexpected value in it?
Yes, indeed. And being able to disable struct default constructors would (I
believe anyway) let us fix that in the library too, by forcing initialization
upon
declaration.
Right now, we could write a st
On 11/6/10 12:13 AM, Rainer Deyke wrote:
On 11/5/2010 17:41, Walter Bright wrote:
In other words, I create an array that I mean to fill in later, because
I don't have meaningful data for it in advance.
That's a faulty idiom. A data structure that exists but contains no
valid data is a bug wai
On Sat, Nov 6, 2010 at 12:23 PM, Denis Koroskin <2kor...@gmail.com> wrote:
> On Sat, 06 Nov 2010 14:06:20 +0300, Christopher Bergqvist <
> ch...@digitalpoetry.se> wrote:
>
> Does D have anything comparable to C++ references à la "void
>> nullCheckLessFunction(const std::string& notNullStr) {...}"
Sat, 06 Nov 2010 13:18:34 +0100, Lutger wrote:
> retard wrote:
>
>> Sat, 06 Nov 2010 10:20:24 +0100, Simen kjaeraas wrote:
>>
>>> Walter Bright wrote:
>>>
Consider non-nullable type T:
T[] a = new T[4];
>>>
>>> As others have pointed out, this would be impossible for a prope
retard wrote:
> Sat, 06 Nov 2010 10:20:24 +0100, Simen kjaeraas wrote:
>
>> Walter Bright wrote:
>>
>>> Consider non-nullable type T:
>>>
>>>T[] a = new T[4];
>>
>> As others have pointed out, this would be impossible for a proper
>> non-nullable type. The only ways to create an array of n
Sat, 06 Nov 2010 10:20:24 +0100, Simen kjaeraas wrote:
> Walter Bright wrote:
>
>> Consider non-nullable type T:
>>
>>T[] a = new T[4];
>
> As others have pointed out, this would be impossible for a proper
> non-nullable type. The only ways to create an array of non-nullable
> elements woul
Sat, 06 Nov 2010 05:04:59 -0400, bearophile wrote:
> To see an example of this, look at this "useless" site
I have ambivalent feelings.. you're beginning to find the joys of irony,
but losing the joys of D :) It's done awful things to me.
Sat, 06 Nov 2010 02:48:02 -0600, Rainer Deyke wrote:
> On 11/6/2010 01:12, spir wrote:
>> On Fri, 05 Nov 2010 23:13:44 -0600 Rainer Deyke
>> wrote:
>>> That's a faulty idiom. A data structure that exists but contains no
>>> valid data is a bug waiting to happen - no, it /is/ a bug, even if it
>>
On Sat, 06 Nov 2010 14:06:20 +0300, Christopher Bergqvist
wrote:
Does D have anything comparable to C++ references à la "void
nullCheckLessFunction(const std::string& notNullStr) {...}" or does it
only
have the equivalent of "void nullCheckingRequired(const std::string*
mightByNullStr) {..
Does D have anything comparable to C++ references à la "void
nullCheckLessFunction(const std::string& notNullStr) {...}" or does it only
have the equivalent of "void nullCheckingRequired(const std::string*
mightByNullStr) {...}"?
Don:
> bearophile wrote:
> > ...
> > http://d.puremagic.com/issues/show_bug.cgi?id=5081
> As was pointed out in a recent post, the return value of a pure function
> is guaranteed to be unique, so could be allowed to implictly cast to
> immutable. I'm planning a patch for that soon, to see how w
Jacob Carlborg:
> Even though he may actually not forget a particular fact it will be
> harder and harder to find the fact because of other things "blocking the
> way". Eventaully it will seem you have forgot the fact.
It's not a block of the way, it's the networks that accumulate noise or just
Simen kjaeraas wrote:
bearophile wrote:
Simen kjaeraas:
Not sure. This way is more explicit, and errors will be caught at
compile-time.
I see. But if a syntax is ugly and too much heavy, people (rightly)
don't use it... (This is why bounded values are good as builtins).
Of course. No
bearophile wrote:
Simen kjaeraas:
Not sure. This way is more explicit, and errors will be caught at
compile-time.
I see. But if a syntax is ugly and too much heavy, people (rightly)
don't use it... (This is why bounded values are good as builtins).
Of course. Now, aliases help a bit her
On 2010-11-06 05:46, bearophile wrote:
Walter Bright:
Yeah, well, my brain is full. In order to learn new facts, I must discard an
equivalent number of existing ones. I've had to discard everything I ever
learned about chemistry, for example.
As a human brain gets older, its ability to quickl
bearophile wrote:
J. M. Berger:
Consider immutable type immutable T:
immutable T] a = new immutable T[4];
... time goes by ...
T[1] = foo;
T[3] = bar;
In other words I create an array that I mean to fill in later,
because I don't have meaningful data for it in advance. How do I do
th
Simen kjaeraas:
> Not sure. This way is more explicit, and errors will be caught at
> compile-time.
I see. But if a syntax is ugly and too much heavy, people (rightly) don't use
it... (This is why bounded values are good as builtins).
Bye,
bearophile
bearophile wrote:
Simen kjaeraas:
Bounded!(int, 1, 5)[] myArr;
myArr ~= 1; // Compile-time error: int is not implicitly castable to
Bounded!(int, 1, 5)
myArr ~= Bounded!(int, 1, 5)( 1 ); // Works perfectly
I can't say this is a nice syntax :-)
(Isn't the implicit conversion + bound test bet
Simen kjaeraas:
> Bounded!(int, 1, 5)[] myArr;
> myArr ~= 1; // Compile-time error: int is not implicitly castable to
> Bounded!(int, 1, 5)
> myArr ~= Bounded!(int, 1, 5)( 1 ); // Works perfectly
I can't say this is a nice syntax :-)
(Isn't the implicit conversion + bound test better?)
Bye,
be
Simen kjaeraas:
> As others have pointed out, this would be impossible for a proper
> non-nullable type. The only ways to create an array of non-nullable
> elements would be a literal, concatenation with non-nullable elements,
> or casting an existing array of nullable elements.
>
> You do not ha
Walter Bright wrote:
Adam D. Ruppe wrote:
It wasn't until I added the invariant and in/out contracts to all the
functions
asserting about null that the problem's true cause became apparent.
Couldn't this happen to you with any datum that has an unexpected value
in it?
Yes. And by augme
J. M. Berger:
>
> Consider immutable type immutable T:
>
> immutable T] a = new immutable T[4];
> ... time goes by ...
> T[1] = foo;
> T[3] = bar;
>
> In other words I create an array that I mean to fill in later,
> because I don't have meaningful data for it in advance. How do I do
>
Walter Bright wrote:
Consider non-nullable type T:
T[] a = new T[4];
As others have pointed out, this would be impossible for a proper
non-nullable type. The only ways to create an array of non-nullable
elements would be a literal, concatenation with non-nullable elements,
or casting an e
Walter:
> An example would be the bucket array for a hash table. It starts out
> initially
> empty, and values get added to it. I have a hard time agreeing that such a
> ubiquitous and useful data structure is a bad idiom.
I agree, there are several situations where nulls are important and ver
1 - 100 of 199 matches
Mail list logo
