Walter Bright:
What would be cool, though, is a linker
that is able to do more advanced things -
This may be useful as guide (not used by LDC yet):
http://llvm.org/docs/GoldPlugin.html
Bye,
bearophile
Don wrote:
It seems that pure and nothrow are attributes, just like @safe.
(By contrast, you can overload functions based on const and immutable).
Should the names be changed?
Definitely. And what about @deprecated and @override?
-Lars
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
As I understand it, one of the characteristics of attributes is that you
should be able to remove them from the entire program, without affecting
the
On Fri, 27 Nov 2009 12:09:05 +0300, Don nos...@nospam.com wrote:
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
As I understand it, one of the characteristics of attributes is that you
should be
dsimcha wrote:
I would say that @safe doesn't make much sense. What if you're implementing
your
comparison function using memcmp() or something else that involves a bunch of
pointers? If you pass memcmp() invalid parameters, it can segfault, and would
therefore have to be marked as unsafe,
On Fri, 27 Nov 2009 12:30:30 +0300, Lars T. Kyllingstad
pub...@kyllingen.nospamnet wrote:
Denis Koroskin wrote:
On Fri, 27 Nov 2009 12:09:05 +0300, Don nos...@nospam.com wrote:
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think
Walter Bright:
Naked is not an externally visible attribute of a function, signature or
type, it only concerns the internals. Therefore, it shouldn't be an
attribute.
On the other hand I agree with them that currently naked is not in the best
place. So let's try another alternative:
void
Nurse, Nurse - take this cork off the end of my fork - I'm trying to eat.
On Fri, 27 Nov 2009 12:50:19 +0300, bearophile bearophileh...@lycos.com
wrote:
Walter Bright:
Naked is not an externally visible attribute of a function, signature or
type, it only concerns the internals. Therefore, it shouldn't be an
attribute.
On the other hand I agree with them that
Graham St Jack:
I have been dabbling with the shared and immutable keywords in an effort
to find out if they are usable, and aren't getting anywhere.
Thank you for reminding me that tuning D for performance is premature
optimization :-)
Bye,
bearophile
Don wrote:
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
As I understand it, one of the characteristics of attributes is that you
should be able to remove them from the entire program, without
On Fri, 27 Nov 2009 13:58:59 +0300, Don nos...@nospam.com wrote:
Denis Koroskin wrote:
On Fri, 27 Nov 2009 12:50:19 +0300, bearophile
bearophileh...@lycos.com wrote:
Walter Bright:
Naked is not an externally visible attribute of a function, signature
or
type, it only concerns the
I think that in the current design of safety, @trusted function and normal
functions are quite similar. An @unsafe proposal has been rejected because of
complexity.
But here is a case that is left.
Sometimes in D1, I found that a function I tought trustworthy is in fact
completely buggy. I
On Fri, 27 Nov 2009 13:56:10 +0300, Lars T. Kyllingstad
pub...@kyllingen.nospamnet wrote:
Don wrote:
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
As I understand it, one of the characteristics of
Denis Koroskin:
I think do not affect the generated code is a bit restricting.
[...] There are endless possibilities.
Lombok gives annotations to reduce boring lines of Java code:
http://projectlombok.org/features/index.html
Some of those annotations:
@Getter / @Setter: Never write public int
Denis Koroskin wrote:
On Fri, 27 Nov 2009 13:58:59 +0300, Don nos...@nospam.com wrote:
Denis Koroskin wrote:
On Fri, 27 Nov 2009 12:50:19 +0300, bearophile
bearophileh...@lycos.com wrote:
Walter Bright:
Naked is not an externally visible attribute of a function,
signature or
type, it
#ponce wrote:
I think that in the current design of safety, @trusted function and normal
functions are quite similar. An @unsafe proposal has been rejected because of
complexity.
No it hasn't been rejected. It's implemented in D2.037 (it's called
@system now).
Lars T. Kyllingstad wrote:
Don wrote:
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
As I understand it, one of the characteristics of attributes is that
you should be able to remove them from the
Don wrote:
Lars T. Kyllingstad wrote:
Don wrote:
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
As I understand it, one of the characteristics of attributes is that
you should be able to remove
Op Fri, 27 Nov 2009 11:58:59 +0100 schreef Don nos...@nospam.com:
void foo()
@naked body
{
LOL! Spam filters would love that!!
I can already imagine the jokes spreading over the internets:
@safe public double penetration(of a) @naked body { ... }
Denis Koroskin, el 27 de noviembre a las 12:17 me escribiste:
On Fri, 27 Nov 2009 12:09:05 +0300, Don nos...@nospam.com wrote:
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
As I understand it, one
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
dsimcha wrote:
I would say that @safe doesn't make much sense. What if you're
implementing your
comparison function using memcmp() or something else that involves a bunch
of
pointers? If you pass memcmp() invalid
Don wrote:
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
As I understand it, one of the characteristics of attributes is that you
should be able to remove them from the entire program, without
dsimcha wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
dsimcha wrote:
I would say that @safe doesn't make much sense. What if you're implementing
your
comparison function using memcmp() or something else that involves a bunch of
pointers? If you pass memcmp()
dsimcha wrote:
I think you misunderstood the argument. memcmp() could be @trusted if functions
only need to be safe when passed valid parameters, though I don't necessarily
agree that this makes sense. I was thinking memcmp() shouldn't even be marked
@trusted because it's so easy to invoke
Don wrote:
It seems to me that one of the most important features of SafeD is that
whenever a @safe function invokes a function, it does so only with valid
parameters. The problem with memcmp() is that the required relationship
between the parameters is complicated, and can't be determined
Hello Walter,
there's no
way that an @safe function can guarantee it sends memcmp() arguments
that will work safely with memcmp().
I think that's backwards. There's no way memcmp can be sure it's arguments
are safe just because it's being called from a @safe function.
OTOH, if a @trusted
Walter Bright wrote:
dsimcha wrote:
I think you misunderstood the argument. memcmp() could be @trusted if
functions
only need to be safe when passed valid parameters, though I don't
necessarily
agree that this makes sense. I was thinking memcmp() shouldn't even
be marked
@trusted because
Ary Borenszweig wrote:
Don wrote:
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
As I understand it, one of the characteristics of attributes is that
you should be able to remove them from the
Andrei Alexandrescu wrote:
Walter Bright wrote:
dsimcha wrote:
I think you misunderstood the argument. memcmp() could be @trusted
if functions
only need to be safe when passed valid parameters, though I don't
necessarily
agree that this makes sense. I was thinking memcmp() shouldn't even
== Quote from Don (nos...@nospam.com)'s article
Andrei Alexandrescu wrote:
Walter Bright wrote:
dsimcha wrote:
I think you misunderstood the argument. memcmp() could be @trusted
if functions
only need to be safe when passed valid parameters, though I don't
necessarily
agree that
On Fri, 27 Nov 2009 23:51:44 +0300, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Walter Bright wrote:
dsimcha wrote:
I think you misunderstood the argument. memcmp() could be @trusted if
functions
only need to be safe when passed valid parameters, though I don't
necessarily
On Sat, 28 Nov 2009 00:20:47 +0300, dsimcha dsim...@yahoo.com wrote:
== Quote from Don (nos...@nospam.com)'s article
Andrei Alexandrescu wrote:
Walter Bright wrote:
dsimcha wrote:
I think you misunderstood the argument. memcmp() could be @trusted
if functions
only need to be safe when
dsimcha:
Isn't overflowing a signed int undefined behavior?
Yes, it can be.
If so, how would we eliminate undefined behavior without very expensive
runtime checks?
I have explained LLVM devs how to speed-up some of those runtime checks.
Do you exactly know how much expensive they are, in
Denis Koroskin:
I don't think integer overflow could be considered an undefined behavior.
It's pretty much expected that uint.max + 1 == 0.
Computers are (mostly) deterministic, so in a certain sense everything they do
can be expected :-)
But sometimes the programmer forgets or doesn't take
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
On Sat, 28 Nov 2009 00:20:47 +0300, dsimcha dsim...@yahoo.com wrote:
== Quote from Don (nos...@nospam.com)'s article
Andrei Alexandrescu wrote:
Walter Bright wrote:
dsimcha wrote:
I think you misunderstood the argument.
Don wrote:
It seems that pure and nothrow are attributes, just like @safe.
(By contrast, you can overload functions based on const and immutable).
Should the names be changed?
This runs into another issue I was thinking about.
So I'm working on this property rewrite thing that does the
Hello,
I've been reading the forums for some time, but this is my first post here :-)
I am trying to create yet another D2 wrapper for SQLite. As usual with many C
libraries, SQLite provides us some objects and functions to create and
destroy them. So, I decided to encapsulate these SQLite
LMB Wrote:
Hello,
[...]
Ouch! I thought I was posting to the learn group. My bad, sorry!
On Sat, 28 Nov 2009 01:27:41 +0300, LMB lmbar...@gmail.com wrote:
Hello,
I've been reading the forums for some time, but this is my first post
here :-)
I am trying to create yet another D2 wrapper for SQLite. As usual with
many C libraries, SQLite provides us some objects and functions
Don wrote:
Andrei Alexandrescu wrote:
Walter Bright wrote:
dsimcha wrote:
I think you misunderstood the argument. memcmp() could be @trusted
if functions
only need to be safe when passed valid parameters, though I don't
necessarily
agree that this makes sense. I was thinking memcmp()
Denis Koroskin wrote:
On Fri, 27 Nov 2009 23:51:44 +0300, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Walter Bright wrote:
dsimcha wrote:
I think you misunderstood the argument. memcmp() could be @trusted
if functions
only need to be safe when passed valid parameters, though I
dsimcha wrote:
Quick question about the eliminating undefined behavior thing: Isn't
overflowing
a signed int undefined behavior?
No. On every 2's complement machine I've ever heard of, the behavior is
defined and the same.
Andrei Alexandrescu wrote:
b) incorrect addresses within the application, erroneous result returned
I think it would be implementation-defined behavior - in case (b) memcmp
would return an implementation-defined value but still defined.
How could it?
dsimcha wrote:
What about int.max + 1? I specifically mentioned **signed** integers because,
IIRC overflowing these is undefined in C, but overflowing unsigned is defined.
It's undefined behavior in C because C supports ones-complement
arithmetic. D does not - twos-complement only.
One thing Java and Python, Ruby, etc., still hold over D is dynamic
classes, i.e. classes that are only known at runtime, not compile time.
In D, this:
s.foo(3);
could be emulated with:
s.dynamicMethod(foo, 3);
Unfortunately, that makes it impossible to use s with generic code
Making them not virtual would also make them not overridable, they'd all
be implicitly final.
Is there any compelling use case for virtual operator overloads? Keep in
mind that any non-virtual function can still be a wrapper for another
virtual method, so it is still possible (with a bit of
Walter Bright wrote:
Andrei Alexandrescu wrote:
b) incorrect addresses within the application, erroneous result
returned
I think it would be implementation-defined behavior - in case (b)
memcmp would return an implementation-defined value but still defined.
How could it?
The value itself
Walter Bright wrote:
One thing Java and Python, Ruby, etc., still hold over D is dynamic
classes, i.e. classes that are only known at runtime, not compile time.
In D, this:
s.foo(3);
could be emulated with:
s.dynamicMethod(foo, 3);
Unfortunately, that makes it impossible to use s
On Sat, 28 Nov 2009 02:32:21 +0300, Walter Bright
newshou...@digitalmars.com wrote:
Making them not virtual would also make them not overridable, they'd all
be implicitly final.
Is there any compelling use case for virtual operator overloads? Keep in
mind that any non-virtual function
On Sat, 28 Nov 2009 00:30:14 +0100, Walter Bright
newshou...@digitalmars.com wrote:
One thing Java and Python, Ruby, etc., still hold over D is dynamic
classes, i.e. classes that are only known at runtime, not compile time.
In D, this:
s.foo(3);
could be emulated with:
Andrei Alexandrescu wrote:
Let's not confuse undefined with implementation-defined. I am firmly
convinced that memcmp never falls in the undefined behavior realm. The
behavior is always defined.
Makes sense. But I'd still want to make it not @safe, by using a more
expansive definition of
Simen kjaeraas wrote:
davidl implemented this as opDotExp in Fully dynamic d by opDotExp
overloading
(http://www.digitalmars.com/webnews/newsgroups.php?article_id=88145).
Thanks for the ref. On one page linkies:
Walter Bright:
One thing Java and Python, Ruby, etc., still hold over D is dynamic
classes, i.e. classes that are only known at runtime, not compile time.
I see, you want a Swiss army knife language :o)
Before choosing a design I suggest to look at how both Java and C#4 have done
it, few
Walter Bright wrote:
Andrei Alexandrescu wrote:
Let's not confuse undefined with implementation-defined. I am firmly
convinced that memcmp never falls in the undefined behavior realm. The
behavior is always defined.
Makes sense. But I'd still want to make it not @safe, by using a more
Walter Bright wrote:
Simen kjaeraas wrote:
davidl implemented this as opDotExp in Fully dynamic d by opDotExp
overloading
(http://www.digitalmars.com/webnews/newsgroups.php?article_id=88145).
Thanks for the ref. On one page linkies:
Walter Bright wrote:
And clearly, this idea was proposed before, including the templated
version.
I also see (reading it) that it was pretty thoroughly discussed. I'm
convinced we should do it.
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Making them not virtual would also make them not overridable, they'd all
be implicitly final.
Is there any compelling use case for virtual operator overloads? Keep in
mind that any non-virtual function can still be a wrapper
bearophile wrote:
I see, you want a Swiss army knife language :o)
Before choosing a design I suggest to look at how both Java and C#4 have done
it, few random links about C#4:
http://msdn.microsoft.com/en-us/library/dd264736%28VS.100%29.aspx
Andrei Alexandrescu wrote:
Denis Koroskin wrote:
Points 2 and 3 introduce undefined behavior, which is not allowed in
SafeD :p
s/undefined/implementation-defined/
Behavior is only implementation-defined if the implementation actually
defines it. When targeting a specific implementation of
Denis Koroskin wrote:
snip
Lower bound is always 0 in D, unlike VB where is can take an arbitrary
value. As such, there is no need for opLowerBound in D.
Only for built-in linear arrays. Half the point is: What if somebody
creates a type for which the lower bound is something different?
Fri, 27 Nov 2009 15:32:21 -0800, Walter Bright wrote:
Making them not virtual would also make them not overridable, they'd all
be implicitly final.
Is there any compelling use case for virtual operator overloads? Keep in
mind that any non-virtual function can still be a wrapper for another
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
bearophile wrote:
I see, you want a Swiss army knife language :o)
Before choosing a design I suggest to look at how both Java and C#4 have
done
it, few random links about C#4:
== Quote from retard (r...@tard.com.invalid)'s article
Fri, 27 Nov 2009 15:32:21 -0800, Walter Bright wrote:
Making them not virtual would also make them not overridable, they'd all
be implicitly final.
Is there any compelling use case for virtual operator overloads? Keep in
mind that
dsimcha wrote:
Sometimes I feel like there should be a law similar to Greenspun's Law for
language design:
Any sufficiently long-lived language that promises to be simpler than C++ and
D
will grow to contain an ad-hoc, bug-ridden, informally specified, slow
implementation of half of C++ and D.
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
dsimcha wrote:
Sometimes I feel like there should be a law similar to Greenspun's Law for
language design:
Any sufficiently long-lived language that promises to be simpler than C++
and D
will grow to contain an
I have a feeling that the safeD thing is a bit premature. I'm only
posting this because then I can link to this post next summer, when it's
becoming clear that I was right. Because I'm such a nice guy I won't
even save this link. :P
Noone's ever tried this feature in real code that people
dsimcha wrote:
Right, but sometimes (though certainly not always) it's better to provide a
meta-feature that solves a whole bunch of problems (like better templates) and
then solve the individual problems at the library level, rather than add a
language feature specifically to address each need.
On Fri, 27 Nov 2009 22:58:00 -0500, retard r...@tard.com.invalid wrote:
Fri, 27 Nov 2009 15:32:21 -0800, Walter Bright wrote:
Making them not virtual would also make them not overridable, they'd all
be implicitly final.
Is there any compelling use case for virtual operator overloads? Keep in
Walter Bright wrote:
One thing Java and Python, Ruby, etc., still hold over D is dynamic
classes, i.e. classes that are only known at runtime, not compile time.
In D, this:
s.foo(3);
could be emulated with:
s.dynamicMethod(foo, 3);
Unfortunately, that makes it impossible to use s
Hi All,
I am using QtD to do some gui stuff. As the QtD documentation described, Qt-
data types should be declared with keyword scope, so that all variables
can be deallocated in a right order.
I found a memory leak problem accidentally, when I executed the following
code very frequently:
//
miriac Wrote:
I really do want to stick to tongo, i instaled it with the instructions in
the tongo book but i can try downlding it again and see if it works
thanks
Below link contains information on how to setup Tango workspace:
http://www.dsource.org/projects/tango/forums/topic/827
Hope
Hello,
This should be my first post here, but I just posted the same message on the
standard D newsgroup by mistake (what a noob! :-P) So, here I go again, on
the right forum this time...
I am trying to create yet another D2 wrapper for SQLite. As usual with many C
libraries, SQLite provides
Don wrote:
Bill Baxter wrote:
On Tue, Nov 17, 2009 at 4:17 AM, Don nos...@nospam.com wrote:
Bill Baxter wrote:
On Tue, Nov 17, 2009 at 2:07 AM, Don nos...@nospam.com wrote:
Travis Boucher wrote:
I've been playing with string mixins, and they are very powerful.
One thing I can't figure out
Hi,
I'm contemplating using D for an embedded project where system
configuration registers have fixed memory locations.
One way of doing it would be to have a constant pointer to a structure
with manually aligned members that match the register map, and access
them like that. This becomes
http://d.puremagic.com/issues/show_bug.cgi?id=3553
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||patch
--- Comment #2 from
http://d.puremagic.com/issues/show_bug.cgi?id=3521
--- Comment #2 from Don clugd...@yahoo.com.au 2009-11-27 00:15:10 PST ---
I investigated this a bit, so far without success. I'm writing notes here for
when I come back to it.
It's something to do with the register allocation. The compiler is
http://d.puremagic.com/issues/show_bug.cgi?id=3553
Brad Roberts bra...@puremagic.com changed:
What|Removed |Added
CC||bra...@puremagic.com
http://d.puremagic.com/issues/show_bug.cgi?id=3554
Summary: Ddoc generats invalid output for documentation
comments with non paired paranthasis
Product: D
Version: 2.032
Platform: Other
OS/Version: Linux
Status:
80 matches
Mail list logo