On 08/11/2010 14:35, steveh wrote:
bearophile Wrote:
Simen kjaeraas:
Context-sensitive constructor disabling is a theoretical possibility, but
seems to me to conflict with D's other goals.
It's time to update those goals.
I studied the situation further. Now I've decided to leave D. I
On Thu, 25 Nov 2010 16:14:11 +
Bruno Medeiros brunodomedeiros+s...@com.gmail wrote:
What they don't realize, is that static typing is just compile-time
unit-testing. :)
I tried to find some light on this topic a while ago, because similar arguments
are constantly brought on the carpet,
Jonathan M Davis jmdavisp...@gmx.com wrote:
We definitely want to avoid the nastier issues, but the lack of default
constructors continually pops up as being a major problem. The QtD folks
in
particular were have a lot of problems because of it as I understand.
I've
certainly had problems
On Tuesday 09 November 2010 02:22:31 Simen kjaeraas wrote:
Jonathan M Davis jmdavisp...@gmx.com wrote:
We definitely want to avoid the nastier issues, but the lack of default
constructors continually pops up as being a major problem. The QtD folks
in
particular were have a lot of problems
Nick Sabalausky schrieb:
so s...@so.do wrote in message news:op.vlv3iukp7dt...@so-pc...
There's no usage of an undeclared variable, but the right-hand-side of
the
second line uses 'i' before *the programmer* initializes it. Yes, the D
compiler chooses to automatically initialize it, but by
Daniel Gibson metalcae...@gmail.com wrote:
Nick Sabalausky schrieb:
so s...@so.do wrote in message news:op.vlv3iukp7dt...@so-pc...
There's no usage of an undeclared variable, but the right-hand-side
of the
second line uses 'i' before *the programmer* initializes it. Yes, the
D
compiler
Daniel Gibson metalcae...@gmail.com wrote in message
news:ibbp25$ls...@digitalmars.com...
Nick Sabalausky schrieb:
so s...@so.do wrote in message news:op.vlv3iukp7dt...@so-pc...
There's no usage of an undeclared variable, but the right-hand-side of
the
second line uses 'i' before *the
Nick Sabalausky a...@a.a wrote in message
news:ibc4h2$1mm...@digitalmars.com...
Daniel Gibson metalcae...@gmail.com wrote in message
news:ibbp25$ls...@digitalmars.com...
Nick Sabalausky schrieb:
so s...@so.do wrote in message news:op.vlv3iukp7dt...@so-pc...
There's no usage of an undeclared
Simen kjaeraas simen.kja...@gmail.com wrote in message
news:op.vlwul8tuvxi...@biotronic-pc.lan...
Daniel Gibson metalcae...@gmail.com wrote:
Nick Sabalausky schrieb:
so s...@so.do wrote in message news:op.vlv3iukp7dt...@so-pc...
There's no usage of an undeclared variable, but the
Nick Sabalausky a...@a.a wrote in message
news:ibc5ve$1q7...@digitalmars.com...
Simen kjaeraas simen.kja...@gmail.com wrote in message
news:op.vlwul8tuvxi...@biotronic-pc.lan...
Yup. Also, as opposed to certain other solutions, it does not require
advanced flow control, that is likely to be
Nick Sabalausky a...@a.a wrote:
Also, as I've said when this was discussed in the past, I wouldn't even
want
the flow analysis to be perfect because all that would accomplish is to
encourage garbage like the above (which would just end up being highly
fragile anway).
But if it isn't, we
I agree with Nick Sabalausky in this discussion.
Simen kjaeraas:
But if it isn't, we must either define what it should do, or accept that
some compilers will catch some of the uninitialized variable bugs, where
others do not. We do not want that.
Right. There are ways to write formal specs
so Wrote:
At initialization rvalue should not contain anything about
lvalue, this is absurd.
That may well be the case.
I was only pointing out that as far as the Microsoft
compiler is concerned, saying the code:
'compiles with no warning, no error, nothing...'
is incorrect. It
Eric Poggel dnewsgro...@yage3d.net wrote:
On 11/6/2010 6:50 AM, bearophile wrote:
foobar:
Any type can be wrapped by an OPTION type. trying to do the converse
of this is impractical and is bad design.
Discussing this is a waste of time now, this part of the D language
will probably
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
On 11/7/10 4:21 PM, bearophile wrote:
Andrei Alexandrescu:
And what was exactly the claim that was wrong?
That there is no need of compiler syntax support to implement good
enough nonnullable reference types in D.
The only
On Mon, 08 Nov 2010 12:08:01 +0300, Simen kjaeraas
simen.kja...@gmail.com wrote:
Eric Poggel dnewsgro...@yage3d.net wrote:
On 11/6/2010 6:50 AM, bearophile wrote:
foobar:
Any type can be wrapped by an OPTION type. trying to do the converse
of this is impractical and is bad design.
Simen kjaeraas:
Context-sensitive constructor disabling is a theoretical possibility, but
seems to me to conflict with D's other goals.
It's time to update those goals.
Bye,
bearophile
On Monday 08 November 2010 01:10:07 Simen kjaeraas wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
On 11/7/10 4:21 PM, bearophile wrote:
Andrei Alexandrescu:
And what was exactly the claim that was wrong?
That there is no need of compiler syntax support to implement
Jonathan M Davis jmdavisp...@gmx.com wrote:
??? Structs have no default constructor.
True. Disabling the default constructor here means that
struct Foo{
@disable this();
}
Foo f;
should halt compilation at Foo f;, and certain other places where a
default constructor would normally be
bearophile Wrote:
Simen kjaeraas:
Context-sensitive constructor disabling is a theoretical possibility, but
seems to me to conflict with D's other goals.
It's time to update those goals.
I studied the situation further. Now I've decided to leave D. I tried to cope
with all overly
steveh Wrote:
bearophile Wrote:
Simen kjaeraas:
Context-sensitive constructor disabling is a theoretical possibility, but
seems to me to conflict with D's other goals.
It's time to update those goals.
I studied the situation further. Now I've decided to leave D. I tried to
Intensive test suites guarantee safety and quality. An extreme version of TDD.
sounds good, but strong typesystem pissed poeple normaly don't tend to
write such suit code - they just talk about writing it
and btw: TDD means Test Driven Development, but in real life it seems to
be Trial
steveh wrote:
less types = better
Then no types are best?
Do have some fun with assembler.
-manfred
On Monday, November 08, 2010 05:01:57 Simen kjaeraas wrote:
Jonathan M Davis jmdavisp...@gmx.com wrote:
??? Structs have no default constructor.
True. Disabling the default constructor here means that
struct Foo{
@disable this();
}
Foo f;
should halt compilation at Foo f;, and
bearophile wrote:
In practice on average my small Python programs are less buggy than my small D
ones.
One's experience with a particular language can have a very strong influence on
how buggy one's code is.
D's type system is also designed for large systems. For small programs, static
Jonathan M Davis wrote:
On Monday, November 08, 2010 05:01:57 Simen kjaeraas wrote:
Jonathan M Davis jmdavisp...@gmx.com wrote:
??? Structs have no default constructor.
True. Disabling the default constructor here means that
struct Foo{
@disable this();
}
Foo f;
should halt compilation
I studied the situation further. Now I've decided to leave D. I tried to
cope with all overly complex type system quirks, but have had enough of
it now. These two months with D truly opened my eyes. It means I won't
touch C++ or Java either.
My next goal is to use an untyped (less types =
On Monday, November 08, 2010 10:06:35 Walter Bright wrote:
Jonathan M Davis wrote:
I was not aware of that. I didn't think that you could do that for
structs since default constructors are illegal in the first place. It
would likely have the negative side effect of making it illegal to put
Jonathan M Davis jmdavisp...@gmx.com wrote:
I was not aware of that. I didn't think that you could do that for
structs since
default constructors are illegal in the first place.
And you can't. That doesn't mean it can't be possible in the future.
It would likely have the
negative side
On 11/8/10 1:10 AM, Simen kjaeraas wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
On 11/7/10 4:21 PM, bearophile wrote:
Andrei Alexandrescu:
And what was exactly the claim that was wrong?
That there is no need of compiler syntax support to implement good
enough
Jonathan M Davis wrote:
How hard would it really be to insert code wherever a struct's init value is
used to default construct it either when the program starts up (for globals) or
right after it's declared (for locals)? If you could do that, then I don't see
why we couldn't have proper
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Jonathan M Davis wrote:
How hard would it really be to insert code wherever a struct's init value is
used to default construct it either when the program starts up (for
globals) or
right after it's declared (for locals)?
dsimcha wrote:
While I'm also skeptical of the idea that simply declaring a variable can cause
arbitrarily complex code to be executed, I'll play Devil's Advocate a little:
What if we required the default struct constructor to be nothrow? We could also
require some level of purity (at least
On Monday, November 08, 2010 15:23:40 Walter Bright wrote:
dsimcha wrote:
While I'm also skeptical of the idea that simply declaring a variable can
cause arbitrarily complex code to be executed, I'll play Devil's
Advocate a little: What if we required the default struct constructor to
be
On Monday 08 November 2010 20:10:42 Walter Bright wrote:
Jonathan M Davis wrote:
Well, if it's a default constructer which has to be nothrow and maybe
pure or nothing, I'll take the default constructor. Now, if there's a
better way to handle this which would result in full-blown, arbitrary
Walter Bright newshou...@digitalmars.com wrote in message
news:ib87ai$26u...@digitalmars.com...
Nick Sabalausky wrote:
Well I'll be damned, even C/C++ knows that uninitialized variables
shouldn't be used, and yet D doesn't. This is where Walter claims that
getting rid of that warning
so s...@so.do wrote in message news:op.vlubxy2a7dt...@so-pc...
int i;
i = i + 5;
I can't see any uninitialized var there, can you? :P
There's no usage of an undeclared variable, but the right-hand-side of the
second line uses 'i' before *the programmer* initializes it. Yes, the D
compiler
There's no usage of an undeclared variable, but the right-hand-side of
the
second line uses 'i' before *the programmer* initializes it. Yes, the D
compiler chooses to automatically initialize it, but by doing so it
silently
creates a bug every time the programmer intends 'i' to start out as
so s...@so.do wrote in message news:op.vlua80b47dt...@so-pc...
I think I figured out what you meant. When I said C# got it right, you
thought I was talking about how C# doesn't allow any int x = void;
whatsoever, right? That's not what I meant. I was talking about how C#
issues a compile-time
so s...@so.do wrote in message news:op.vlv3iukp7dt...@so-pc...
There's no usage of an undeclared variable, but the right-hand-side of
the
second line uses 'i' before *the programmer* initializes it. Yes, the D
compiler chooses to automatically initialize it, but by doing so it
silently
Walter Bright wrote:
I see no reason why people would do that. It doesn't save typing, it
isn't convenient, etc.
What I mean is that I've never seen anyone do that, and I've seen a lot of junk
people did to shut the compiler up.
Walter Bright newshou...@digitalmars.com wrote in message
news:ib5bue$2ld...@digitalmars.com...
Jonathan M Davis wrote:
Going C# or Java's route forces the programmer to initialize variables
even in cases where they know that it's not necessary (which is annoying
but may or may not be worth
Jonathan M Davis Wrote:
On Saturday 06 November 2010 19:05:32 Nick Sabalausky wrote:
foobar f...@bar.com wrote in messagend in a pointlessly roundabout way.
2. null is an a type-system attribute, hence should be checked at
compile time and would have ZERO affect on run-time
On Sun, 07 Nov 2010 07:20:10 -0500
foobar f...@bar.com wrote:
Simple, ain't it? And it supports Walter's convoluted examples AND is
explicit about it so it prevents illegal operations at compile time.
... AND it makes to safe case default ;-)
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
On Sunday 07 November 2010 04:20:10 foobar wrote:
Both the current D way and the C# way are ugly hacks.
Ideally you should have TWO types: T and Option!T (ignore syntax for now).
Most of the time you would use:
auto variable = new T(params); // no need for nulls here!
and for the
Sun, 07 Nov 2010 01:54:24 -0500, Nick Sabalausky wrote:
Nick Sabalausky a...@a.a wrote in message
news:ib5ht0$2uf...@digitalmars.com...
Walter Bright newshou...@digitalmars.com wrote in message
news:ib5bue$2ld...@digitalmars.com...
Jonathan M Davis wrote:
Going C# or Java's route forces the
foobar Wrote:
Jonathan M Davis Wrote:
On Saturday 06 November 2010 19:05:32 Nick Sabalausky wrote:
foobar f...@bar.com wrote in messagend in a pointlessly roundabout
way.
2. null is an a type-system attribute, hence should be checked at
compile time and would have ZERO
On Sun, 07 Nov 2010 18:01:32 +0300, steveh steve...@hotmai.l wrote:
Sounds more retarded than the notorious 'retard' here. It's because of
people like u that D3 might not come. If you disagree too much with AA
and WB they have no interest to make D3. This nonnull question might be
good
Nick Sabalausky:
You can label C#-style init-checking wishy-washy all you want, but that's
still a hell of a lot better than wrong, which is what D does (as
evidenced by my first example above).
I think all you have written in this post is correct. In this regard D is
better than C and C#
On 11/7/10 9:08 AM, Denis Koroskin wrote:
On Sun, 07 Nov 2010 18:01:32 +0300, steveh steve...@hotmai.l wrote:
Sounds more retarded than the notorious 'retard' here. It's because of
people like u that D3 might not come. If you disagree too much with AA
and WB they have no interest to make D3.
On 11/7/2010 1:02 AM, Walter Bright wrote:
Jonathan M Davis wrote:
Going C# or Java's route forces the programmer to initialize variables
even in cases where they know that it's not necessary (which is
annoying but may or may not be worth it),
Correct. It's not that doing flow analysis is
On 11/7/2010 10:51 AM, Roman Ivanov wrote:
On 11/7/2010 1:02 AM, Walter Bright wrote:
Jonathan M Davis wrote:
Going C# or Java's route forces the programmer to initialize variables
even in cases where they know that it's not necessary (which is
annoying but may or may not be worth it),
On Sat, 06 Nov 2010 13:30:56 +0200, foobar f...@bar.com wrote:
bearophile Wrote:
foobar:
Any type can be wrapped by an OPTION type. trying to do the converse
of this is impractical and is bad design.
Discussing this is a waste of time now, this part of the D language
will probably
so:
Fine having a nun-null type or ranged integer or special float whatever in
a language library,
but asking a new syntax for it? Not really.
There's no way you may implement all the relative semantics in the D language.
You and Andrei are wrong.
Bye,
bearophile
On a related note, I *hate* that D silently sticks in a default value
whenever anything isn't properly inited. This is one thing where I really
think C# got it right, and D got it wrong. And waving the It's not
leaving
it with an undefined value like C does! banner is an irritating
strawman:
Roman Ivanov isroman@ete.km.ru wrote:
I know what your mean, but the example is flawed:
public void foo()
{
if (m) {
Object p = new Object();
p.toString();
}
}
You misunderstand. The idea is this:
void foo( ) {
Object p;
if ( m ) {
p = new Object( );
Simen kjaeraas simen.kja...@gmail.com wrote in message
news:op.vls9bigxvxi...@biotronic-pc.lan...
Roman Ivanov isroman@ete.km.ru wrote:
I know what your mean, but the example is flawed:
public void foo()
{
if (m) {
Object p = new Object();
p.toString();
}
steveh steve...@hotmai.l wrote in message
news:ib6f0c$2s4...@digitalmars.com...
Sounds more retarded than the notorious 'retard' here. It's because of
people like u that D3 might not come. If you disagree too much with AA and
WB they have no interest to make D3. This nonnull question might
so s...@so.do wrote in message news:op.vls71ytk7dt...@so-pc...
On a related note, I *hate* that D silently sticks in a default value
whenever anything isn't properly inited. This is one thing where I really
think C# got it right, and D got it wrong. And waving the It's not
leaving
it with an
foobar f...@bar.com wrote in message news:ib5l2a$1v...@digitalmars.com...
Nick Sabalausky Wrote:
foobar f...@bar.com wrote in message
news:ib3a8k$1i5...@digitalmars.com...
1. the INVENTOR of the reference concept himself admits that this is
a
flawed design.
see:
Nick Sabalausky a...@a.a wrote:
If you do that, then there's two possibilities:
A. You intended p to get inited on all code paths but forgot a codepath.
With real init-checking the compiler will tell you and you can fix it.
With
D as it is, you're not informed at all, and you may or may not
bearophile bearophileh...@lycos.com wrote in message
news:ib6fuj$3j...@digitalmars.com...
This paper contains the solution of about 1/4 of the problems, that may
require a @notDelayed attribute (the other problems are collection
initialization and simplified typestate management):
Simen kjaeraas simen.kja...@gmail.com wrote in message
news:op.vltiombuvxi...@biotronic-pc.lan...
Nick Sabalausky a...@a.a wrote:
If you do that, then there's two possibilities:
A. You intended p to get inited on all code paths but forgot a codepath.
With real init-checking the compiler will
Nick Sabalausky a...@a.a wrote:
- if ( m 12 ) {
+ if ( p m 12 ) {
And you can toss in an if(m12) assert(p); if you're worried about
that.
Of course. But the point is, this is unnecessary. We know p !is null
when m 4.
--
Simen
Nick Sabalausky:
Also, I'm curious what you mean by collection initialization and
simplified typestate management.
Collections, like an array, need a temporary transient state where they may
contain nulls too.
The simple typestate management means that if you want to implement nonnull
Simen kjaeraas wrote:
You misunderstand. The idea is this:
void foo( ) {
Object p;
if ( m ) {
p = new Object( );
p.DoSomethingThatNeedsToBeDoneNow( );
}
// 20 lines of code here
if ( m ) {
p.doSomethingWeird( dataFromAbove );
}
}
You're right, the real cases where this
I think it's reasonable to let the current references and pointers
continue to be as they are, and work on @disable (particularly its
interaction with constructors) to make it easy to implement restricted
subsets of values. Then NonNull would be a useful library artifact among
other ones.
Andrei Alexandrescu:
And what was exactly the claim that was wrong?
That there is no need of compiler syntax support to implement good enough
nonnullable reference types in D.
What's a relative semantics?
- The limited form of typestate change, as shown in the original Spec# paper
I've
In the end seeing the amount of holes left in the design of the D module
system and immutables, this nonnull design may be too much hard for D,
most people here don't even see 1/2 of the problems needed to implement
nonnullables well enough. So maybe we are just wasting time here. D
so:
You are saying as it is something trivial. :)
Const/Immutable is one of the most important and complex part of a
language.
Sorry, I didn't mean to sound like that. It's indeed hard to design the
immutable system of D. And my mind is not good enough yet to design it.
Nonetheless there
On 11/7/10 4:21 PM, bearophile wrote:
Andrei Alexandrescu:
And what was exactly the claim that was wrong?
That there is no need of compiler syntax support to implement good enough
nonnullable reference types in D.
The only change needed is constructor flow to make sure types with
Sun, 07 Nov 2010 14:09:01 -0800, Walter Bright wrote:
Simen kjaeraas wrote:
You misunderstand. The idea is this:
void foo( ) {
Object p;
if ( m ) {
p = new Object( );
p.DoSomethingThatNeedsToBeDoneNow( );
}
// 20 lines of code here
if ( m ) {
p.doSomethingWeird(
That's why we have immutable variables. They force you to think what to
put in the variables. A lot of cases like the one above would be solved
if if-then-else was an functional expression instead of a void returning
statement. C/C++/D has the ternary ?: but the syntax is obfuscated.
Object p =
On 11/6/2010 6:50 AM, bearophile wrote:
foobar:
Any type can be wrapped by an OPTION type. trying to do the converse of this is
impractical and is bad design.
Discussing this is a waste of time now, this part of the D language will
probably never change.
This is why other people and me are
Simen kjaeraas simen.kja...@gmail.com wrote in message
news:op.vltjpebhvxi...@biotronic-pc.lan...
Nick Sabalausky a...@a.a wrote:
- if ( m 12 ) {
+ if ( p m 12 ) {
And you can toss in an if(m12) assert(p); if you're worried about
that.
Of course. But the point is, this is
Walter Bright newshou...@digitalmars.com wrote in message
news:ib783u$1od...@digitalmars.com...
The real problem with the spurious errors is that then people will put in
an initialization just to shut the compiler up. Time passes, and the
next guy is looking at the code and wonders why x is
so s...@so.do wrote in message news:op.vltk19pq7dt...@so-pc...
On Sun, 07 Nov 2010 22:41:41 +0200, Nick Sabalausky a...@a.a wrote:
so s...@so.do wrote in message news:op.vls71ytk7dt...@so-pc...
On a related note, I *hate* that D silently sticks in a default value
whenever anything isn't
Nick Sabalausky a...@a.a wrote in message
news:ib84bo$1vc...@digitalmars.com...
so s...@so.do wrote in message news:op.vltk19pq7dt...@so-pc...
On Sun, 07 Nov 2010 22:41:41 +0200, Nick Sabalausky a...@a.a wrote:
so s...@so.do wrote in message news:op.vls71ytk7dt...@so-pc...
On a related note,
Nick Sabalausky wrote:
Well I'll be damned, even C/C++ knows that uninitialized variables shouldn't
be used, and yet D doesn't. This is where Walter claims that getting rid of
that warning improves safety because it prevents people from shutting the
compiler up by changing this:
int i = i +
I think I figured out what you meant. When I said C# got it right, you
thought I was talking about how C# doesn't allow any int x = void;
whatsoever, right? That's not what I meant. I was talking about how C#
issues a compile-time error whenever a variable is read before it's
guaranteed to have
On Mon, 08 Nov 2010 08:17:09 +0200, Jussi Jumppanen jus...@zeuseedit.com
wrote:
so Wrote:
Not related to this but i have to share.
Try compiling this in C/C++.
int i = i + 5; // something like this.
void main()
{
int i = i + 5; // something like this.
}
Microsoft (R) 32-bit C/C++
1. the INVENTOR of the reference concept himself admits that this is a flawed
design.
see:
http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake
2. null is an a type-system attribute, hence should be checked at compile
time and would have ZERO affect on
foobar:
Any type can be wrapped by an OPTION type. trying to do the converse of this
is impractical and is bad design.
Discussing this is a waste of time now, this part of the D language will
probably never change.
This is why other people and me are proposition something different.
Bye,
bearophile Wrote:
foobar:
Any type can be wrapped by an OPTION type. trying to do the converse of
this is impractical and is bad design.
Discussing this is a waste of time now, this part of the D language will
probably never change.
This is why other people and me are proposition
Sat, 06 Nov 2010 07:30:56 -0400, foobar wrote:
Disabling stuff is a BAD design and
is bug-prone. The language should be additive, i.e. I should be
writing what I want to do, NOT listing all the possible things that I
DON'T want to do.
Then why are you here?
retard Wrote:
Sat, 06 Nov 2010 07:30:56 -0400, foobar wrote:
Disabling stuff is a BAD design and
is bug-prone. The language should be additive, i.e. I should be
writing what I want to do, NOT listing all the possible things that I
DON'T want to do.
Then why are you here?
You just
bearophile Wrote:
foobar:
Any type can be wrapped by an OPTION type. trying to do the converse of
this is impractical and is bad design.
Discussing this is a waste of time now, this part of the D language will
probably never change.
This is why other people and me are proposition
steveh steve...@useshotmai.l wrote:
I've known there are hidden tradeoffs when using these 'intelligent'
types. Non-null types add terrible runtime checks everywhere. It's
simply not acceptable in a systems programming language. Operating
system kernel uses very efficient uninitialized
steveh:
I've known there are hidden tradeoffs when using these 'intelligent' types.
Right, every design has some trade-offs.
Non-null types add terrible runtime checks everywhere.
This is not true. They may add some runtime checks, but in practice you
normally need to perform those cheeks
steveh wrote:
Non-null types add terrible runtime checks everywhere.
No they don't. They *remove* runtime checks everywhere.
There are only two possible situations for a given pointer:
1. You know that it cannot be null. In that case, you use a
non-nullable type for that pointer to
foobar f...@bar.com wrote in message
news:ib3a8k$1i5...@digitalmars.com...
1. the INVENTOR of the reference concept himself admits that this is a
flawed design.
see:
http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake
First of all, appeal to
On Saturday 06 November 2010 19:05:32 Nick Sabalausky wrote:
foobar f...@bar.com wrote in messagend in a pointlessly roundabout way.
2. null is an a type-system attribute, hence should be checked at
compile time and would have ZERO affect on run-time performance.
Same as assigning a
Jonathan M Davis wrote:
Going C# or Java's route forces the programmer to
initialize variables even in cases where they know that it's not necessary
(which is annoying but may or may not be worth it),
Correct. It's not that doing flow analysis is hard, it's that it's impossible to
do it
93 matches
Mail list logo
