not make this
explicit by prefixing an 'r' to these reverse iteration functions?
--
Rainer Deyke - rain...@eldwood.com
: negative = bad, positive = good :D
I don't like this. !empty reads better than nonEmpty, and empty
reads much better than !nonEmpty.
--
Rainer Deyke - rain...@eldwood.com
.
a !op b == !(a op b), but only for op in some limited set that
doesn't include all operators with which you might want to use the
pattern: less consistent; requires memorization.
--
Rainer Deyke - rain...@eldwood.com
' as '!(a
= b)' would be very weird and inconsistent with other languages.)
I'm not suggesting that anybody should actually /use/ the '!+' operator,
even if it was defined. That would be horrible.
--
Rainer Deyke - rain...@eldwood.com
for error
reporting ever a good idea in a high-level language?) It also adds
awkward expressions to the language, not just in the form '!(a b)',
but in the form '!(a ! b)'.
--
Rainer Deyke - rain...@eldwood.com
Daniel Keep wrote:
Rainer Deyke wrote:
This is, in my opinion, a significant design error in the language. The
difference between '!(a b)' and 'a ! b' is not obvious. There is
nothing about the operator '' that suggests that it should set a global
exception state, and there is nothing
it. I don't believe it actually exists.
--
Rainer Deyke - rain...@eldwood.com
, but due to programmer error,
the slicing problem still exists.
--
Rainer Deyke - rain...@eldwood.com
(*this));
}
};
class avatar : public person, public deity {
avatar(avatar const org, bool allow_slicing = false)
: person(org, true)
{
}
};
Fix 2:
Trust the programmer to pay attention and remove the silly unnecessary
assertion from class 'person'.
--
Rainer Deyke - rain...@eldwood.com
or totally fix it at the language level in D
without sacrificing inheritance for value types.
--
Rainer Deyke - rain...@eldwood.com
) {
this.value = v;
}
this(this) {
this.value = this.value.dup;
}
~this() {
delete this.v;
}
T opDot() {
return this;
}
T value;
}
--
Rainer Deyke - rain...@eldwood.com
Christopher Wright wrote:
Rainer Deyke wrote:
What mechanism for sharing state is available to by-reference objects
but not by-value objects?
struct C {
T t;
}
C c1;
C c2 = c1;
If T was a reference type, 'c1' and 'c2' now share state, and it's up to
the programmer to write code
that C++ doesn't have problems of its own
- clearly it does, or I wouldn't be looking at D.
--
Rainer Deyke - rain...@eldwood.com
Tom S wrote:
Rainer Deyke wrote:
Because you can't correctly duplicate a multi-dimensional dynamic array
in D by using the built-in 'dup' property.
Simply because shallow copies are the default. Usually you can't even
have automatic deep copies. What if the array was supposed
passing unadorned dynamic
arrays around.
--
Rainer Deyke - rain...@eldwood.com
slicing.
Reference semantics, heap storage, RAII (with reference counting):
Reference types with destructors that actually work.
--
Rainer Deyke - rain...@eldwood.com
. Stick to C++ for now, but
come back in a year or two when D 2.0 has had time to stabilize.
--
Rainer Deyke - rain...@eldwood.com
pointers even in D2. A
language like Python may not need them, but then Python has reference
counting and destructors that actually work in addition to garbage
collection. And weak references.
--
Rainer Deyke - rain...@eldwood.com
Bill Baxter wrote:
4..$
4u..$
etc?
Aside from the inconsistent meaning of $, you still can't have an
inclusive range [a, b], where 'a' and 'b' are not only known at runtime,
without treating 'b == int.max' as a special case.
--
Rainer Deyke - rain...@eldwood.com
run Japanese console applications, but console
applications that assume CP437 or Latin-1 don't work for me.
--
Rainer Deyke - rain...@eldwood.com
. It is a serious bug if
they don't.
The conversion cannot be performed at any other level. D uses unicode
internally. The console uses a specific encoding. Therefore all data
passing between D and the console must be encoded/decoded.
--
Rainer Deyke - rain...@eldwood.com
reference argument for every
function is tedious.
--
Rainer Deyke - rain...@eldwood.com
you where.
I use assertions because they make my life easier.
--
Rainer Deyke - rain...@eldwood.com
Walter Bright wrote:
Rainer Deyke wrote:
I use assertions because they make my life easier.
Yeah, but you also said they were tedious g.
Tedious, but better than the same code without the assertions.
Non-nullable types would remove the need for manual assertions.
--
Rainer Deyke - rain
Georg Wrede wrote:
Rainer Deyke wrote:
A sample size of one doesn't mean much. In my experience, none of those
four factors account for a significant amount of bugs, since all of them
(except integer overflow) can be caught without too much effort through
the copious use of assertions
support for
nullable types, you could always use a dynamic array or some othet
container instead.
--
Rainer Deyke - rain...@eldwood.com
problems. This is not
true of pretty much any other type of application.
If you spend hundreds of milliseconds on garbage collection every ten
second, you spend multiple percent of your total execution time on
garbage collection. I wouldn't consider that acceptable anywhere.
--
Rainer Deyke
worth discussing.)
--
Rainer Deyke - rain...@eldwood.com
to be released in a timely
manner. The other 50% does not need RAII, but also wouldn't benefit
from GC in any area other than performance.
--
Rainer Deyke - rain...@eldwood.com
', or '**o == 5'.
--
Rainer Deyke - rain...@eldwood.com
like this criticism applies as much to Scala as it
does to D and Java.
--
Rainer Deyke - rain...@eldwood.com
of custom
utilities are all I need.
--
Rainer Deyke - rain...@eldwood.com
allows it.
--
Rainer Deyke - rain...@eldwood.com
the difference between logical const and physical
const. I use the logical const features of C++ (along with the
'mutable' keyword) in C++ all the time for just this purpose. For
better or worse, D has gone the physical const route.
--
Rainer Deyke - rain...@eldwood.com
Aenigmatic wrote:
Is typedef (in D) a C/C++ legacy or is the dear orphan now adopted as
a first-class citizen in the US of D?
typedef in D is a new feature not found in C or C++.
The typedef from C/C++ has been renamed to alias and extended to
non-types in D.
--
Rainer Deyke - rain
features would be much more
useful (and much easier to sell) than yet another incompatible
object-oriented C variant.
--
Rainer Deyke - rain...@eldwood.com
to upgrade their CPUs, you just
wasted twenty to fifty million dollars of your customers' money (or,
more likely, lost a million customers).
--
Rainer Deyke - rain...@eldwood.com
::ColorFormat;
This way I don't pollute my outer namespaces with enum symbols.
--
Rainer Deyke - rain...@eldwood.com
to
hire competent programmers in the first place.
--
Rainer Deyke - rain...@eldwood.com
);
assert(rhs.equals(cast(T) this) == result);
return result;
}
}
This, on the other hand, does require two layers of functions if you
want to remove the infinite recursion by replacing the 'equals' in the
assertion with 'doEquals'.
--
Rainer Deyke - rain...@eldwood.com
; // Reuse variable.
}
}
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).
--
Rainer Deyke - rain...@eldwood.com
at the evidence and arrive at exactly the wrong
conclusion. Declaring variables as close as possible to where they are
used can reduce stack usage, and never increases it.
--
Rainer Deyke - rain...@eldwood.com
, and a good one.
You could argue that assigned a 'B' to a variable that is declared to
hold an 'A' is already a memory safety violation. If so, then the exact
argument also applies to assigning 'null' to the same variable.
--
Rainer Deyke - rain...@eldwood.com
.
--
Rainer Deyke - rain...@eldwood.com
not.
--
Rainer Deyke - rain...@eldwood.com
' after 'z'.
- [0 ... uint.max] is possible.
--
Rainer Deyke - rain...@eldwood.com
Chris Nicholson-Sauls wrote:
My personal experience with Scala, at least, has been that it doesn't
hurt anything.
Scala uses the Java garbage collector, which can take all kinds of abuse
without flinching.
--
Rainer Deyke - rain...@eldwood.com
Jeremie Pelletier wrote:
struct NonNull(C) if(is(C == class)) {
C ref;
invariant() { assert(ref !is null); }
T opDot() { return ref; }
}
This only catches null errors at runtime. The whole point of a non-null
type is to catch null errors at compile time.
--
Rainer Deyke
Jeremie Pelletier wrote:
Rainer Deyke wrote:
This only catches null errors at runtime. The whole point of a non-null
type is to catch null errors at compile time.
Thats what flow analysis is for, since these are mostly uninitialized
variables rather than null ones.
Nitpick
signature is a necessary feature of multiple
inheritance, or even a particularly well thought-out one. Python is an
example of a language without this feature, and multiple inheritance
is very common in Python.
--
Rainer Deyke - rain...@eldwood.com
uninitialized, there is no need to initialize the variable at runtime.
--
Rainer Deyke - rain...@eldwood.com
and unsafe).
Boost.Units (C++) checks units at compile time. There is no reason why
D could not use the same approach.
--
Rainer Deyke - rain...@eldwood.com
this, although in general it's
probably better to stick with SI units in your code and only perform
conversions on input/output.
--
Rainer Deyke - rain...@eldwood.com
this is a big deal either
way. Unit errors should be exceedingly rare. The purpose of a unit
library not to track down unit errors, but to formally prove that
correct code is correct.
--
Rainer Deyke - rain...@eldwood.com
4, but both are acceptable to me.
--
Rainer Deyke - rain...@eldwood.com
will automatically benefit.
FWIW I use boost::rational quite a bit, and I've never felt the need to
use bigints.
--
Rainer Deyke - rain...@eldwood.com
);
out {
assert(value == top());
assert(length == old length + 1);
}
The syntax with 'old' is more concise, easier to read, and does the same
thing. What's wrong with it (other than adding yet another keyword to
the language)?
--
Rainer Deyke - rain...@eldwood.com
.
W: Nobody complained about it with slices.
FWIW, I found arrays in D1 so completely broken that I didn't it worth
the effort to complain about every little detail. Everything about them
was wrong. I consider them a textbook example of what not to do.
--
Rainer Deyke - rain...@eldwood.com
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
To answer the rephrased question: 'int[new]' should be a value type.
Well Walter and I agreed they should be pass-by-reference. That doesn't
mean they must be references, and the fact that the simplest syntax has
the worst efficiency reminds me
because
slices can't be assigned to arrays), the cornerstone of your argument
goes away.
Actually [1, 2, 3] looks more like an array than a slice to me. Arrays
can be assigned to slices, no?
--
Rainer Deyke - rain...@eldwood.com
;
}
--
Rainer Deyke - rain...@eldwood.com
. I don't think it should be dismissed out of hand.
--
Rainer Deyke - rain...@eldwood.com
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
I honestly believe the whole old thing can't be made to work. Shall we
move on to other possibilities instead of expending every effort on
making this bear dance?
It definitely /can/ be made to work, for some value of work. It
sacrifices
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
Also, from the Eiffel docs
(http://archive.eiffel.com/doc/online/eiffel50/intro/language/invitation-07.html):
The notation 'old expression' is only valid in a routine
postcondition. It denotes the value the expression had on routine entry
Christopher Wright wrote:
Rainer Deyke wrote:
It seems that Eiffel had 'old' semantics that I've proposed all along.
Any significant problems with this approach would have been discovered
by the Eiffel community by now.
It requires duplicating the object. If the object is mutable
Leandro Lucarella wrote:
Rainer Deyke, el 17 de octubre a las 14:24 me escribiste:
There is no the object.
There is an object if you have this:
void f(SomeObjectWithLotsOfReferences obj) out {
assert(old(obj).some_check());
}
If 'obj' is a reference type and the reference itself wasn't
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
Copying the object would be completely broken, so I'm sure that that's
*not* how Eiffel does it. It denotes the value the expression had on
routine entry. In other words, the expression is evaluated once, on
routine entry, and the result
, but it's not prohibitively difficult either.
--
Rainer Deyke - rain...@eldwood.com
Rainer Deyke wrote:
{
auto old_x = x;
try {
F();
} finally {
G(old_x);
}
}
Not 'finally', unless postconditions are checked when the function
terminates with an exception. This is closer to correct:
{
auto old_x = x;
// Preconditions go here.
F
the Eiffel community would know
about it.
--
Rainer Deyke - rain...@eldwood.com
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
The expression may mutate stuff.
It shouldn't. It's an error if it does, just like it's an error for an
assertion or post/precondition to have any side effects.
It would be nice if the compiler could catch this error, but failing
that, 'old
Andrei Alexandrescu wrote:
I hereby suggest we get rid of new for class object creation. What do
you guys think?
*applause*
'X(x)' and 'new X(x)' have distinct meanings in C++. In Java/C#/D, the
'new' is just line noise.
--
Rainer Deyke - rain...@eldwood.com
.
--
Rainer Deyke - rain...@eldwood.com
Denis Koroskin wrote:
On Tue, 20 Oct 2009 03:00:57 +0400, Rainer Deyke rain...@eldwood.com
wrote:
Andrei Alexandrescu wrote:
One surprising (but safe) behavior that remains with slices is this:
void fun(int[] a) {
a[0] = 0;
a ~= 42;
a[0] = 42;
}
The caller may or may not see
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
Your definition of safe is clearly not aligned with mine.
What's yours?
Safety is not an absolute, but a question of degree. The harder it is
to write incorrect code, the safer the language.
One key element of this is deterministic behavior
Bill Baxter wrote:
On Mon, Oct 19, 2009 at 4:00 PM, Rainer Deyke rain...@eldwood.com wrote:
'X(x)' and 'new X(x)' have distinct meanings in C++. In Java/C#/D, the
'new' is just line noise.
Well, I think new Foo is how you create a struct on the heap in D.
So it's not exactly line noise.
I
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
If the caller wasn't expecting the array to be modified, then that's a
textbook case of memory corruption.
[citation needed]
I guess we need to define memory corruption first. Memory corruption
is when a piece of code erroneously overwrites
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
I guess we need to define memory corruption first. Memory corruption
is when a piece of code erroneously overwrites memory.
Where's that quote from?
It's my own attempt to define memory corruption. It's equivalent to the
definition
that for a class type 'X', 'new X'
allocates a *reference*, not an instance, on the heap.
--
Rainer Deyke - rain...@eldwood.com
' variant that uses a single global mutex.
RAII wrappers over global initialization/deinitialization functions.
A 'UniqueId' struct that initializes to a value that is guaranteed to be
distinct from the vale of any other 'UniqueId' used by the program.
--
Rainer Deyke - rain...@eldwood.com
.)
--
Rainer Deyke - rain...@eldwood.com
be computed through iteration with a generic
algorithm. The idea is to not force containers to write that themselves
or ungainly cache the length.
If the length is often needed, caching is much more efficient than
recalculating from scratch.
--
Rainer Deyke - rain...@eldwood.com
Simen Kjaeraas wrote:
On Thu, 22 Oct 2009 05:39:10 +0200, Rainer Deyke rain...@eldwood.com
wrote:
Trivial solution: use indentation. If a line is more deeply indented
than the previous line, it's a continuation of the previous statement.
All spaces, I presume? :p
Tabs wouldn't
backwards: downcasting is allowed while upcasting is prohibited.
Just like contravariant functions. Only less so.
--
Rainer Deyke - rain...@eldwood.com
mind if they were removed
entirely. However, the prefix versions should be kept, and allowed in
compound expressions.
--
Rainer Deyke - rain...@eldwood.com
the power of the 'version' construct in order to prevent overly
complex read-only code.
--
Rainer Deyke - rain...@eldwood.com
package; D has 'std'.
--
Rainer Deyke - rain...@eldwood.com
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
'-safe' turns on runtime safety checks, which can be and should be
mostly orthogonal to the module safety level.
Runtime vs. compile-time is immaterial.
The price of compile-time checks is that you are restricted to a subset
of the language
hand-waving.
--
Rainer Deyke - rain...@eldwood.com
Andrei Alexandrescu wrote:
Oh how cool. So it turns out that SafeD can be 100% implemented on a
safe VM.
This is also true of regular unsafe C.
--
Rainer Deyke - rain...@eldwood.com
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
You're forgetting about all other system programming languages.
Delphi.
Also,
many of these claims to safety are demonstrably false.
Which?
I can get Python to segfault.
Memory safety is defined formally in Pierce's book.
Do you mean
can accidentally have two
variables pointing at the same buffer. Let's say one buffer holds
network input and the other holds some bytecode to execute. Boom - a
bug that can be exploited to execute malicious (byte-)code.
--
Rainer Deyke - rain...@eldwood.com
+ rhs.data;
else static if (op == opSub) return data - rhs.data;
...
else static assert(0, Method ~op~ not implemented);
}
I'd much rather have opUnknownMethod than opBinary. If if I have
opUnknownMethod, then opBinary becomes redundant.
--
Rainer Deyke - rain...@eldwood.com
, to deal with the
other 99.9% of cases precisely and being conservative in 0.1% of
cases is
really of no practical significance.
Yes, but a moving GC needs to be 100% precise, not 99.9%.
--
Rainer Deyke - rain...@eldwood.com
dsimcha wrote:
== Quote from Rainer Deyke (rain...@eldwood.com)'s article
Yes, but a moving GC needs to be 100% precise, not 99.9%.
Not if you allow pinning, which we'd need anyhow for untyped, conservatively
scanned memory blocks.
If you allow pinning then you no longer get the full
place is not defined.
Incidentally, it is sometimes possible to send output to a physical
device by merely reading from a memory-mapped I/O address. Therefore
the set of possible results of memcmp includes sending garbage output to
a physical device.
--
Rainer Deyke - rain...@eldwood.com
Pelle Månsson wrote:
File looks like a constructor. You are not constructing a file you open
for reading.
open by itself is ambiguous. What are you opening? A window? A
network port? I think the word file needs to be in there somewhere to
disambiguate.
--
Rainer Deyke - rain
Pelle Månsson wrote:
Rainer Deyke wrote:
open by itself is ambiguous. What are you opening? A window? A
network port? I think the word file needs to be in there somewhere to
disambiguate.
Something like new BufferedReader(new FileReader(foo.txt))? It's quite
unambiguous.
No, like
. all objects are in the same
state as they were before the function was called. (The strong
exception guarantee.)
--
Rainer Deyke - rain...@eldwood.com
this bother me.
--
Rainer Deyke - rain...@eldwood.com
1 - 100 of 372 matches
Mail list logo
