Daniel Keep wrote:
Maybe the compiler could rewrite the above as:
auto t = a.b;
t.c = 3;
a.b = t;
Unless it can prove it doesn't need to. Same solution as to the op=
conundrum.
Yes! At least that's what the user wants.
The compiler has to detect, that the object was modified at all. (To
kn
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 10:16:33 -0400, grauzone wrote:
Daniel Keep wrote:
Maybe the compiler could rewrite the above as:
auto t = a.b;
t.c = 3;
a.b = t;
Unless it can prove it doesn't need to. Same solution as to the op=
conundrum.
Yes! At least that'
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 14:22:26 -0400, grauzone wrote:
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 10:16:33 -0400, grauzone wrote:
Daniel Keep wrote:
Maybe the compiler could rewrite the above as:
auto t = a.b;
t.c = 3;
a.b = t;
Unless it can prove it
Chad J wrote:
Thinking about it a little more, the extra temporaries could run you out
of registers. That still sounds like a negligable cost in most code.
Temporaries can be on the stack. That's not a problem.
Walter Bright wrote:
Currently, that can't be done. But it would be good to get it in for D2.
What for?
Frank Benoit wrote:
KennyTM~ schrieb:
Frank Benoit wrote:
Or how about making it a single method?
bool empty=(bool* value){
if( value ) _empty = *value;
return _empty;
}
The compiler rewrites the calling code to either pass the address or
null.
So properties can't be used in SafeD?
I think this feels like a desperate grasping-at-straws attempt to not
add a keyword (even though pure, nothrow, shared, __gshared, and
immutable all seem to have made it in without any great fanfare).
Don't forget the introduction of ref and macro, which broke backwards
compatibility in D1. mac
Ary Borenszweig wrote:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
The next step would be to introduce user defined annotations. I propose
this:
//--
//declaring a user defined annotation type
@annotation
struct MyAnnotation {
int x;
char[] y;
Ary Borenszweig wrote:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
The next step would be to introduce user defined annotations. I propose
this:
//--
//declaring a user defined annotation type
@annotation
struct MyAnnotation {
int x;
char[] y;
SubA
Don wrote:
Ary Borenszweig wrote:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
This looks like a solution in search of a problem. What's the problem
being solved?
Attaching additional data to types, that can't be specified otherwhere.
This should help with metaprogramming
yigal chripun wrote:
this is a good start but as already noted by others, you can't specify types with structs. we also can't use type tuples cause of the auto flatten behavior.
And why can't we use structs? Unless I've missed something, it wasn't
explained in this thread.
Kagamin wrote:
grauzone Wrote:
yigal chripun wrote:
this is a good start but as already noted by others, you can't specify types with structs. we also can't use type tuples cause of the auto flatten behavior.
And why can't we use structs? Unless I've missed something, it
Max Samukha wrote:
It would be nice (and that is unlikely to happen) if the compiler
could rewrite
struct Foo
{
@Persistent("db_field")
@Serializable
int field;
}
to
struct Foo
{
int field;
mixin Persistent!("field", "db_field");
mixin Serializable!("field");
}
It'd
Michel Fortin wrote:
Also, I wonder why we need braces everywhere in contracts. I'd like it
if I could write:
int test(int i)
in
assert(i > 1);
out (z)
assert(z < 0);
do
return -i + 1;
Just bikeshedding a bit around... why not make it even simpler, and just
leave away the body/d
torhu wrote:
On 03.08.2009 19:47, Andrei Alexandrescu wrote:
A while ago I mentioned the video of my BoostCon keynote "Iterators Must
Go" will be soon available online. Here it is:
http://boostcon.blip.tv/
Andrei
Cool. I'm having some trouble skipping to the parts I'm interested in,
can an
Daniel Keep wrote:
Yes, but then they're just keywords, with an @ in front. You'd just be
kidding yourself if you think you've reduced the keyword count.
I suspect the reasoning goes like this:
* I want attributes. Walter doesn't see the use.
* Walter complains about adding keywords.
* I can
Daniel Keep wrote:
grauzone wrote:
torhu wrote:
On 03.08.2009 19:47, Andrei Alexandrescu wrote:
A while ago I mentioned the video of my BoostCon keynote "Iterators Must
Go" will be soon available online. Here it is:
http://boostcon.blip.tv/
Andrei
Cool. I'm having some t
Steven Schveighoffer wrote:
For the record, I'm not really keen on using annotations for
*everything* as some people have suggested. They have good uses, but I
Me neither, but I think they'd be a worthy feature. Of course, there are
far more pressing issues, but if Walter has time to introdu
Kagamin wrote:
grauzone Wrote:
inheritance?
You want to inherit annotations? What for?
Backward compatibility: obtain annotation cast it, work with it, then later
change its type. Annotations will be used by reflection, so classinfo will be
useful.
Code can do that at compiletime. No
Bill Baxter wrote:
Interesting thing I found out about C# properties.
The syntax
int Thing {
get { return _thing; }
set { _thing = value; }
}
is rewritten by the C# compiler into
int prop_Thing() { return _thing; }
void prop_Thing(int value) { _thing = value; }
Just thought it was inter
bearophile wrote:
Frank Benoit:
Is it the malloc that fails (returning null) or the handling of the block?<
It's the filling of the memory block. malloc by itself doesn't crash.
Then what is there to complain? You know you must check return values.
The D allocation probably fails due to mem
That's great. I think this would finally fix some of the more pressing
issues of D.
I have a question:
will
T[new] a;
allocate something? Or will the allocation of the hidden library array
object delayed until the length is set to non null? If the library array
object is not allocated, will
bearophile wrote:
2. make arrays implementable on .net
I don't care of such thing. dotnet already has C# and C# is probably better
than D, and it's similar anyway. So I don't think people will use D on dotnet.
So even if creating a D for dotnet can be positive, I don't want D2 to change
its
Stewart Gordon wrote:
Moreover, would whatever happens solve such const/invariant holes as bug
2093?
Just what happens to the ~= operator anyway? Right now, it appends data
inline.
My vote would be to make "a~=b" do the same as "a=a~b" (with types "T[]
a" and "T[] b" or "T b"). T[new]'s ~=
Don wrote:
That doesn't work, because you still get new code being converted from
C. It can't look the same, but behave differently.
int* a, b;
Ooops...
Right now, D seems to *intend* to allow arbitrary forward references of
types and functions. But the reality is different. dmd accepts some
forward references, but chokes up on others. For example, forward
references to classes are normally no problem, while enums can't be
forward referenced at
Right now, D seems to *intend* to allow arbitrary forward references of
types and functions. But the reality is different. dmd accepts some
forward references, but chokes up on others. For example, forward
references to classes are normally no problem, while enums can't be
forward referenced at
Jarrett Billingsley wrote:
For two, NO. Disallowing forward references sucks. It's entirely
possible to implement a compiler that resolves forward refs correctly.
If W doesn't want to do it, that's on him.
I agree; but: I'm just saying that disallowing it would actually be
better for the pr
Jarrett Billingsley wrote:
On Tue, Aug 25, 2009 at 10:54 AM, grauzone wrote:
Jarrett Billingsley wrote:
For two, NO. Disallowing forward references sucks. It's entirely
possible to implement a compiler that resolves forward refs correctly.
If W doesn't want to do it, that's o
Robert Fraser wrote:
grauzone wrote:
I agree; but: I'm just saying that disallowing it would actually be
better for the programmer, than leaving it half-broken.
I strongly disagree. Dealing with header files, forward feference
issues, etc. is the #1 reason I don't use C/C++ (reall
Walter Bright wrote:
Tim M wrote:
Walter: may I ask with this, reddit posts and dobb's code post, why
the interest in this particular topic right now? Didn't you implement
this a long time ago?
It was one of the first things implemented in D.
But I was thinking about it lately as I prepare th
Andrei Alexandrescu wrote:
I plan to add a Nullable struct to Phobos (akin to C#'s Nullable,
Boost's Optional).
Apparently a good design is to define Optional!T with a minimum of
member functions (ideally none) and have it use the "alias this" feature
to masquerade as a T. That way Optional!T
Walter Bright wrote:
Jeremie Pelletier wrote:
Now if I only can find enough documentation about OMF to write a COFF
to OMF converter..
http://www.azillionmonkeys.com/qed/Omfg.pdf
What I always wanted to know: besides OPTLINK, is there an OMF linker
that can link D programs?
I couldn't fi
Jarrett Billingsley wrote:
On Thu, Sep 3, 2009 at 6:48 PM, Edward
Diener wrote:
What I imagine will happen in D is that when an updated delegate type allows
itself to be initialized with a function pointer, the vast majority of D
programmers will use delegate for all callables and the function p
Walter Bright wrote:
grauzone wrote:
Walter Bright wrote:
Jeremie Pelletier wrote:
Now if I only can find enough documentation about OMF to write a COFF
to OMF converter..
http://www.azillionmonkeys.com/qed/Omfg.pdf
What I always wanted to know: besides OPTLINK, is there an OMF linker
Jeremie Pelletier wrote:
It is definitely easier to implement scripting languages in D than it is
in other languages such as C/C++. However where I believe V8 (google's
Tools like SWIG are missing in D, and you could claim that D's GC gets
into the way of memory managment (you need a mechanis
Robert Jacques wrote:
On Tue, 22 Sep 2009 12:32:25 -0400, Andrei Alexandrescu
wrote:
Daniel Keep wrote:
[snip]
The problem is that currently you have a class of types which can be
passed as arguments but cannot be returned.
For example, Tango's Variant has this horrible hack where the ACTUA
Steven Schveighoffer wrote:
The solution we ended up using is that *all* streams defined the seek
function, even if they didn't support seeking, and if you called it on
such objects, they just throw an exception.
So, if you want to see if an object supports seeking, you must call the
method +
Andrei Alexandrescu wrote:
downs wrote:
Andrei Alexandrescu wrote:
downs wrote:
With all the neat template tricks we have in 2.0, and since we're
widely redefining the syntax anyway, why not deprecate the current
cast syntax and move it into object.d as a library function?
So instead of cast(
Walter Bright wrote:
It is exactly analogous to a null pointer exception. And it's darned
useful.
On Linux, it just generates a segfault. And then you have no idea where
the program went wrong. dmd outputting incorrect debugging information
(so you have troubles using gdb or even addr2line) d
Walter Bright wrote:
Jarrett Billingsley wrote:
It wouldn't. The compiler wouldn't allow it. It would force you to
initialize it. That is the entire point of nonnull references.
Initialize it to what?
A user-defined default object? What should happen if that default object
is accessed? Throw
Walter Bright wrote:
grauzone wrote:
Walter Bright wrote:
It is exactly analogous to a null pointer exception. And it's darned
useful.
On Linux, it just generates a segfault. And then you have no idea
where the program went wrong. dmd outputting incorrect debugging
information (so you
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
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
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
Denis Koroskin wrote:
Unfortunately, you still have to special-case void type in a lot of
cases. Here are just 2 examples:
And that's why there were ideas to allow declaring void variables.
IMHO these void variables should allow all common operations on normal
variables (assignment, passing as
Jacob Carlborg wrote:
On 9/30/09 22:42, Benji Smith wrote:
Does anybody know of any D libraries implementing or wrapping video
codecs?
I need to read video files (AVI or MPEG would be fine) using DIVX,
XVID, or any other popular codec. In addition to playing those files in
a media player contr
Andrei Alexandrescu wrote:
Jarrett Billingsley wrote:
I think it sounds interesting enough, but I can't help but wonder if
this is a feature that you've really thought through (especially wrt.
how it interacts with mechanisms such as template mixins and normal
symbol inheritance), or if you just
Walter Bright wrote:
Anyhow, I think this issue was beaten to death in the previous thread on
null dereference. I don't wish to divert this thread into rediscussing
I don't want to make this "discussion" even more complicated, but some
people (such as me) like the existing default initializat
Andrei Alexandrescu wrote:
Sean Kelly wrote:
== Quote from Andrei Alexandrescu ([email protected])'s
article
dsimcha wrote:
== Quote from Andrei Alexandrescu ([email protected])'s
article
It is a bad idea because distinguishing between release of (expensive)
resources
Steven Schveighoffer wrote:
immutable(double)[] - The compiler stores a copy of this array somewhere
in ROM and initializes the stack variable with the immutable pointer to
the data.
And what about
void foo(int x) {
auto a = [1, x, 2];
?
Should it create an immutable array on the heap?
Andrei Alexandrescu wrote:
I'm talking with Sean and Walter about taking the first step towards
eliminating delete: defining function clear() that clears the state of
an object. Let me know of what you think.
One problem I encountered is that I can't distinguish between a default
constructor
Andrei Alexandrescu wrote:
I'm talking with Sean and Walter about taking the first step towards
eliminating delete: defining function clear() that clears the state of
an object. Let me know of what you think.
One problem I encountered is that I can't distinguish between a default
constructor
Don wrote:
Not so, Andrei has said that he thinks auto-flattening was a bad idea.
And AFAIK, Walter doesn't disagree.
You should try harder, because if you don't change it soon, it will be
there forever due to compatibility requirements.
Andrei and I, and almost everyone else, have tried to
bearophile wrote:
switch (arg) {
case("-s") {
try {
next_arg = iargs.next();
size = toInt(args[idx++]);
} catch (...) {
throw new Exception("...");
}
}
case("-m") {
printMessages = true;
}
case("-p") // just 1 ist
Walter Bright wrote:
Denis Koroskin wrote:
I just believe rewriting it from scratch will be plain faster. I can
also test the code much easier - if it produces exact same binary then
it works correct.
The dmd front end is also written in a "D-ish" style which should make
translation to D eas
language_fan wrote:
I have little desire to embrace inferior technologies. Attempting OOP on
C is ridiculous, it should be called POOP. It is a personal choice.
They're also developing a C# like language, that uses the GTK object
model as base: http://live.gnome.org/Vala
Max Samukha wrote:
On Sat, 17 Oct 2009 13:28:51 -0500, Andrei Alexandrescu
wrote:
Associative arrays are today quite problematic because they don't offer
any true iteration. Furthermore, the .keys and .values properties create
new arrays, which is wasteful.
Another issue with associative ar
Piotrek wrote:
bearophile Wrote:
I'd really like the "default" iteration on an AA to yield its keys, instead of
values as currently done. Because if I have a key I can find its value, while the
opposite is not possible, so having keys is much more useful. This is true in Python too.
In my dl
Walter Bright wrote:
We both feel that this would simplify D, make it more flexible, and
remove some awkward corner cases like the inability to say a.length++.
How would this remove this corner case?
What do you think?
Whether T[new] is bultin (mostly implemented in the runtime), or a
libr
Andrei Alexandrescu wrote:
Don wrote:
Walter Bright wrote:
The purpose of T[new] was to solve the problems T[] had with passing
T[] to a function and then the function resizes the T[]. What happens
with the original?
The solution we came up with was to create a third array type,
T[new], whi
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
Don wrote:
Walter Bright wrote:
The purpose of T[new] was to solve the problems T[] had with
passing T[] to a function and then the function resizes the T[].
What happens with the original?
The solution we came up with
Andrei Alexandrescu wrote:
I was thinking of solving these issues by keeping an LRU (Least Recently
Used) cache inside the implementation of ~=. The LRU would only have a
few entries (4-8) and would store the parameters of the last ~= calls,
and their cached capacities.
Sounds like a bad hack
Jason House wrote:
Walter Bright Wrote:
Currently, static arrays are (as in C) half-value types and
half-reference types. This tends to cause a series of weird problems and
special cases in the language semantics, such as functions not being
able to return static arrays, and out parameters no
Steven Schveighoffer wrote:
I still think having an Appender object or struct is a worthwhile thing,
the "pre-allocate array then set length to zero" model is a hack at best.
Would that work with Andrei's append cache at all? Setting the length to
zero and then appending is like taking a slice
Andrei Alexandrescu wrote:
grauzone wrote:
Steven Schveighoffer wrote:
I still think having an Appender object or struct is a worthwhile
thing, the "pre-allocate array then set length to zero" model is a
hack at best.
Would that work with Andrei's append cache at all? Setting
Denis Koroskin wrote:
On Wed, 21 Oct 2009 22:41:50 +0400, Andrei Alexandrescu
wrote:
language_fan wrote:
Wed, 21 Oct 2009 12:35:35 -0500, Andrei Alexandrescu thusly wrote:
language_fan wrote:
void main() {
Tuple!(int,int) a; // typeof(this) *is* the official tuple type
STuple!(int,int
Leandro Lucarella wrote:
grauzone, el 21 de octubre a las 22:12 me escribiste:
Or even:
a, b = foo();
or
a, _ = foo();
Works in Python (tm)
_ is a regular symbol (variable name in this case), there is nothing
special about the second form, which is exactly the same as the first. And
I
Andrei Alexandrescu wrote:
Today, structs can't write their own this(). There aren't very solid
reasons for that except that it makes language implementation more
difficult.
I wonder how much of a problem that could be in practice. I realized
today that the "Counted" example - a classic C++ p
dsimcha wrote:
== Quote from grauzone ([email protected])'s article
Andrei Alexandrescu wrote:
I'd really like to know why "scope x = new X();" is "unsafe", while
encouraging doing exactly the same with structs seems to be a perfectly
fine idea. Allocating structs
dsimcha wrote:
== Quote from grauzone ([email protected])'s article
Andrei Alexandrescu wrote:
I'd really like to know why "scope x = new X();" is "unsafe", while
encouraging doing exactly the same with structs seems to be a perfectly
fine idea. Allocating structs
Andrei Alexandrescu wrote:
grauzone wrote:
dsimcha wrote:
== Quote from grauzone ([email protected])'s article
Andrei Alexandrescu wrote:
I'd really like to know why "scope x = new X();" is "unsafe", while
encouraging doing exactly the same with structs see
language_fan wrote:
Wed, 21 Oct 2009 18:29:37 -0400, bearophile thusly wrote:
Why not eliminate the requirement for semicolon statement terminators
(unless there are multiple statements per line)?<
Probably mostly because both some part of D language, some part of the
mind of D developers, and
Steven Schveighoffer wrote:
On Thu, 22 Oct 2009 12:50:21 -0400, grauzone wrote:
dsimcha wrote:
== Quote from grauzone ([email protected])'s article
Andrei Alexandrescu wrote:
I'd really like to know why "scope x = new X();" is "unsafe", while
encouraging doing
Andrei Alexandrescu wrote:
Pelle Månsson wrote:
Andrei Alexandrescu wrote:
Yigal Chripun wrote:
On 23/10/2009 13:02, bearophile wrote:
Chris Nicholson-Sauls:
I prefer this (Scala):
list = list ++ (0 to 10)
That's quite less readable. Scala sometimes has some unreadable
syntax. Python has
Andrei Alexandrescu wrote:
Pelle Månsson wrote:
Andrei Alexandrescu wrote:
Yigal Chripun wrote:
On 23/10/2009 13:02, bearophile wrote:
Chris Nicholson-Sauls:
I prefer this (Scala):
list = list ++ (0 to 10)
That's quite less readable. Scala sometimes has some unreadable
syntax. Python has
Right now, you can catch every exception with "try { something; } catch
{ somethingelse; }".
Can we get rid of this abomination before D2 is finalized? I claim that
it's completely useless, and even more so, every single use of this is a
bug.
If you really want to catch everything, you might
d-noob wrote:
bearophile Wrote:
This post is born from a bug I've just removed.
In the past I have read more than one C coding standard (or better, lists of
coding tips) that warn against bugs caused by ++ and --. They suggest to not
use them compound in expressions. They allow to use them wh
Christopher Wright wrote:
PS: I wonder, should the runtime really execute finally blocks if an
"Error" exception is thrown? (Errors are for runtime errors, Exception
for normal exceptions.) Isn't it dangerous to execute arbitrary user
code in presence of what is basically an internal error?
A
Leandro Lucarella wrote:
grauzone, el 25 de octubre a las 12:09 me escribiste:
Right now, you can catch every exception with "try { something; }
catch { somethingelse; }".
Can we get rid of this abomination before D2 is finalized? I claim
that it's completely useless, and even
Lars T. Kyllingstad wrote:
Kagamin wrote:
Lars T. Kyllingstad Wrote:
// This one fails with the following hilarious message:
// Error: static assert (is(real function() == function)) is false
static assert (is (typeof(&Foo.bar) == function));
Failure is valid, compiler just c
Lars T. Kyllingstad wrote:
grauzone wrote:
Lars T. Kyllingstad wrote:
Kagamin wrote:
Lars T. Kyllingstad Wrote:
// This one fails with the following hilarious message:
// Error: static assert (is(real function() == function)) is
false
static assert (is (typeof(&Foo
BCS wrote:
Hello grauzone,
PS: I wonder, should the runtime really execute finally blocks if an
"Error" exception is thrown? (Errors are for runtime errors, Exception
for normal exceptions.) Isn't it dangerous to execute arbitrary user
code in presence of what is basically an
Don wrote:
Jacob Carlborg wrote:
On 10/28/09 16:32, Don wrote:
Jacob Carlborg wrote:
I have quite a big project and when I compile it I get this internal
compiler error: template.c:806: failed assertion `i < parameters->dim'.
I don't know what could cause that error so I don't know where to lo
Bane wrote:
Following code will freeze app on std.gc.fullCollect(), when sqlite3_close() in
destructor is called. If destructor is called manualy, everything goes ok.
Is it a bug, and if is, with what? It behaves same on winxp64 and centos5.2
using dmd 1.30 and sqlite 3.6.5 or 3.6.19 staticall
Walter Bright wrote:
This is an important topic for anyone who is building software systems
that, if they fail, can cause injury or large property damage.
http://www.reddit.com/r/programming/comments/9z811/safe_systems_from_unreliable_parts/
Clicking on the link linked by your link, I get:
Nick Sabalausky wrote:
"If you use (or admin a project that requires) Tango trunk instead of
0.99.8: Why? (Select all that apply)"
http://www.micropoll.com/akira/mpview/704493-212991
The new stack tracing feature is essential. Normally you'd use a
debugger, but we're talking about D here.
dsimcha wrote:
Is there a way to run a class's c'tor on a block of memory from a template
function? For example:
C newClass(C, CtorArgs...)(CtorArgs args) {
// Allocate, initialize.
// Want to call the c'tor that takes type CtorArgs.
}
Deeply hidden on the Digitalmars homepage, it hin
Don wrote:
Jason House wrote:
Don Wrote:
Leandro Lucarella wrote:
Justin Johansson, el 30 de octubre a las 08:42 me escribiste:
Actually, I think I like that better than 'traits'.
-Lars
I'm in agreement with whoever suggested 'meta' or just about
anything else except 'traits'.
'meta', whi
Andrei Alexandrescu wrote:
This question may actually belong in .learn.
What's exactly eliminated from the header generated with -H? I tried it
just now and was surprised to see that the generated .di file includes
the function bodies of regular (non-template) functions and methods.
I was un
dsimcha wrote:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP8
Abstract:
Currently, the layout of D's runtime type info, or RTTI, is defined in
object.d. The details of how the fields of each instantiation of these classes
are populated are buried deep inside the compiler. If ClassIn
Andrei Alexandrescu wrote:
Something just dawned on me: in safe mode, struct static member
functions will be preferred to struct non-static member functions.
Why?
Consider:
struct List(T) {
T payload;
List * next;
void prepend(List * newNode) {
newNode.next = &this;
}
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
Something just dawned on me: in safe mode, struct static member
functions will be preferred to struct non-static member functions.
Why?
Consider:
struct List(T) {
T payload;
List * next;
void prepend(List
Frank Benoit wrote:
safe should be the default. The unsafe part should take the extra
typing, not the other way. Make the user prefer the safe way.
No. D is not C#.
Ary Borenszweig wrote:
grauzone wrote:
Frank Benoit wrote:
safe should be the default. The unsafe part should take the extra
typing, not the other way. Make the user prefer the safe way.
No. D is not C#.
D is an unsafe language.
C# is a safe language.
Like that? :)
If you mean memory
Andrei Alexandrescu wrote:
grauzone wrote:
Ary Borenszweig wrote:
grauzone wrote:
Frank Benoit wrote:
safe should be the default. The unsafe part should take the extra
typing, not the other way. Make the user prefer the safe way.
No. D is not C#.
D is an unsafe language.
C# is a safe
Walter Bright wrote:
grauzone wrote:
If you mean memory safety, then yes and will probably forever be for
all practical uses (unless D gets implemented on a Java or .net like VM).
A VM is neither necessary nor sufficient to make a language memory safe.
It's all in the semantics o
Walter Bright wrote:
grauzone wrote:
Walter Bright wrote:
grauzone wrote:
If you mean memory safety, then yes and will probably forever be for
all practical uses (unless D gets implemented on a Java or .net like
VM).
A VM is neither necessary nor sufficient to make a language memory
safe
Don wrote:
Lutger wrote:
Don wrote:
...
There is a definite use for such as thing. But the existing toString()
is much, much worse than useless. People think you can do something with
it, but you can't.
eg, people have asked for BigInt to support toString(). That is an
over-my-dead-body.
How
Don wrote:
grauzone wrote:
Don wrote:
Lutger wrote:
Don wrote:
...
There is a definite use for such as thing. But the existing toString()
is much, much worse than useless. People think you can do something
with
it, but you can't.
eg, people have asked for BigInt to support toString().
1 - 100 of 492 matches
Mail list logo
