On Tuesday, August 30, 2011 08:57:53 Mariusz Gliwiński wrote:
> I'm sorry - i provided wrong example. I had property in my code, and he
> didn't complained about getter, but setter (of course he can't diversify by
> different return values).
>
>
> interface Interface
> {
> void method(Inter
Hi,
Thanks for the replies, I was away for a couple of days and I couldn't test
your proposals.
Sadly nothing seemed to work...I checked that the dmd.conf that I think it
was using was actually the one used and also that the DFLAG argument
-L-L/usr/local/lib/lib32 is present.
Running the nm comman
On 8/30/11 12:45 AM, Benjamin Thaut wrote:
Am 30.08.2011 02:56, schrieb Andrei Alexandrescu:
On 8/29/11 4:36 PM, Walter Bright wrote:
On 8/29/2011 2:22 PM, Jonathan M Davis wrote:
Certainly, for the common case, adding move constructors is a needless
complication, and I'd _very_ leery of the r
Am 30.08.2011 02:56, schrieb Andrei Alexandrescu:
On 8/29/11 4:36 PM, Walter Bright wrote:
On 8/29/2011 2:22 PM, Jonathan M Davis wrote:
Certainly, for the common case, adding move constructors is a needless
complication, and I'd _very_ leery of the ramifications of the
compiler not
being able
Jonathan M Davis wrote:
> This seems to compile just fine:
>
> interface Interface
> {
> Interface method();
> }
> class Class : Interface
> {
> Class method() {return new Class;}
> }
>
> The problem is the override keyword. _No_ overriding is going on. _That's_
> why it's complaining.
I'm sor
On 8/30/11, Jonathan M Davis wrote:
> But
> it's
> definitely true that allowing overloads between templatized and
> non-templatized
> functions would be an improvement. Hopefully, we get it at some point.
Seeing as example code that uses such overloading is already in TDPL,
this is probably only
On Tuesday, August 30, 2011 03:44:33 Stephan Soller wrote:
> On 27.08.2011 19:16, Benjamin Thaut wrote:
> > After having used the D 2.0 programming language for a year now and
> > having completed 3 projects with it, I wrote a small article about the
> > problems I had with the D 2.0 programming la
On 27.08.2011 19:16, Benjamin Thaut wrote:
After having used the D 2.0 programming language for a year now and
having completed 3 projects with it, I wrote a small article about the
problems I had with the D 2.0 programming language and what suggestions
I have to improve it.
http://3d.benjamin-t
> What's the way to solve this problem?
This gives you some ideas:
http://research.microsoft.com/pubs/67461/non-null.pdf
Bye,
bearophile
On 8/29/11 4:36 PM, Walter Bright wrote:
On 8/29/2011 2:22 PM, Jonathan M Davis wrote:
Certainly, for the common case, adding move constructors is a needless
complication, and I'd _very_ leery of the ramifications of the
compiler not
being able to rely on a move having the bits stay absolutely i
Walter:
> Fixed. Keep 'em coming!
You are quick :-)
What's the way to solve this problem?
import core.stdc.stdio;
struct NotNull(P) if (__traits(compiles, {P p = null;})) {
private P p;
@disable this();
this(P q) {
assert(q);
p = q;
}
NotNull opAss
Both:
this() @disable;
and
@disable this();
will work, right? I don't think the syntax is that bad.
Anyway this is a great addition. I've seen numerous use-cases for
disabling a struct's default ctor.
On 8/29/2011 5:11 PM, Walter Bright wrote:
On 8/29/2011 4:52 PM, bearophile wrote:
alias NotNull!(Foo*) NFooP;
void bar(NFooP foop) { // Error: variable test2.bar.foop initializer required
for type NotNull!(Foo*)
Looks like you found a bug. I'll take care of it.
Fixed. Keep 'em coming!
htt
On 8/29/2011 4:52 PM, bearophile wrote:
alias NotNull!(Foo*) NFooP;
void bar(NFooP foop) { // Error: variable test2.bar.foop initializer required
for type NotNull!(Foo*)
Looks like you found a bug. I'll take care of it.
Walter:
> I've implemented the ability to disable default initialization. This makes
> it
> practical to implement a library based "NotNull" type without a special
> syntax
> for it. The rationale for this is (rather than making it builtin)
If it works well enough, a syntax is allowed to co
On 30.08.2011 0:22, Walter Bright wrote:
For the latest dmd,
https://github.com/D-Programming-Language/dmd/commit/1193f7828b444056c943742daae0a5ccf262272e
,
I've implemented the ability to disable default initialization. This
makes it practical to implement a library based "NotNull" type without
On 8/29/2011 2:22 PM, Jonathan M Davis wrote:
Certainly, for the common case, adding move constructors is a needless
complication, and I'd _very_ leery of the ramifications of the compiler not
being able to rely on a move having the bits stay absolutely identical (and a
move constructor would mak
On 8/29/2011 2:09 PM, dsimcha wrote:
DMD doesn't even build right now.
Dang ships passing in the night. Fixed.
On Monday, August 29, 2011 13:35 Benjamin Thaut wrote:
> I hoped for a little bit more feedback about the article itself.
> Especially about the move constructor I suggested. Does anyone see a
> need for this, or is it just me?
Honestly, I find the fact that you're writing code which relies on the
On Monday, August 29, 2011 15:18 Mariusz Gliwiński wrote:
> Jonathan M Davis wrote:
> > It's _not_ overriding. It's implementing [...]
>
> Whether it's called overriding or implementing isn't a big deal for me. In
> D we *already* write _override_ keyword to _implement_ method (IMO it's
> good cho
On 8/27/2011 10:14 AM, Benjamin Thaut wrote:
Comments and criticism welcome
This guy wants to contact you:
http://www.reddit.com/r/programming/comments/jwkvx/suggestions_for_the_d_20_programming_language/c2g2wos
On 8/29/2011 1:56 PM, dsimcha wrote:
Oh, one more thing: What about this:
NotNull!(int*) notNull = void;
It's accepted, unless it's in @safe code.
On 8/29/2011 1:32 PM, dsimcha wrote:
How does it work for member variables of classes and structs? E.g.:
// Is this legal or not?
struct Foo
{
NotNull!(int*) notNull;
this(int* ptr)
{
notNull = ptr;
}
}
Try it and see! (It works as you'd expect.)
On 8/29/11 3:46 PM, jdrewsen wrote:
[sni]
Thanks for taking my comments in stride.
* verbose, dataTimeout etc. don't have corresponding properties for
reading.
I general all the settings are simply set directly in libcurl itself.
Libcurl only has a function for setting options and not one for
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> On 8/29/2011 1:32 PM, dsimcha wrote:
> > How does it work for member variables of classes and structs? E.g.:
> >
> > // Is this legal or not?
> > struct Foo
> > {
> > NotNull!(int*) notNull;
> >
> > this(int* ptr)
> >
Oh, one more thing: What about this:
NotNull!(int*) notNull = void;
Jonathan M Davis wrote:
> It's _not_ overriding. It's implementing [...]
Whether it's called overriding or implementing isn't a big deal for me. In D
we *already* write _override_ keyword to _implement_ method (IMO it's good
choice, to match with overriding class methods).
But back to the topi
On 8/29/11 3:22 PM, Walter Bright wrote:
For the latest dmd,
https://github.com/D-Programming-Language/dmd/commit/1193f7828b444056c943742daae0a5ccf262272e
,
I've implemented the ability to disable default initialization. This
makes it practical to implement a library based "NotNull" type without
Den 29-08-2011 20:55, Andrei Alexandrescu skrev:
On 8/17/11 6:12 PM, David Nadlinger wrote:
Now that Lars Kyllingstad's new and improved std.path has passed the
vote – congratulations, Lars! –, and Jose Armando Garcia, the author of
the proposed logging module, is currently not available, the et
On Mon, 29 Aug 2011 22:22:52 +0200, Walter Bright
wrote:
For the latest dmd,
https://github.com/D-Programming-Language/dmd/commit/1193f7828b444056c943742daae0a5ccf262272e
,
I've implemented the ability to disable default initialization. This
makes it practical to implement a library ba
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> For the latest dmd,
>
https://github.com/D-Programming-Language/dmd/commit/1193f7828b444056c943742daae0a5ccf262272e
> ,
> I've implemented the ability to disable default initialization. This makes
> it
> practical to implement
I hoped for a little bit more feedback about the article itself.
Especially about the move constructor I suggested. Does anyone see a
need for this, or is it just me?
--
Kind Regards
Benjamin Thaut
For the latest dmd,
https://github.com/D-Programming-Language/dmd/commit/1193f7828b444056c943742daae0a5ccf262272e
,
I've implemented the ability to disable default initialization. This makes it
practical to implement a library based "NotNull" type without a special syntax
for it. The rationale
On Monday, August 29, 2011 12:53 Alex Rønne Petersen wrote:
> On 29-08-2011 19:47, Jonathan M Davis wrote:
> > On Monday, August 29, 2011 07:44 Steven Schveighoffer wrote:
> >> My opinion is that static methods should *not* be callable from an
> >> instance, you should need typeof(instance).staticM
On Monday, August 29, 2011 14:09 Mariusz Gliwiński wrote:
>
> interface Interface {
> Interface method();
> }
> class Class : Interface {
> override Class method() {}
> }
>
>
> DMD complains it isn't overriding. How should it be according to
> specification, and how about making it legal?
It's
Yeah it's not important. But I'll definitely use the colon syntax more
often now.
On 29-08-2011 19:47, Jonathan M Davis wrote:
On Monday, August 29, 2011 07:44 Steven Schveighoffer wrote:
My opinion is that static methods should *not* be callable from an
instance, you should need typeof(instance).staticMethod. The current
allowance is misleading.
Yeah. I don't know why it's
interface Interface {
Interface method();
}
class Class : Interface {
override Class method() {}
}
DMD complains it isn't overriding. How should it be according to
specification, and how about making it legal?
On 08/29/2011 08:59 PM, Andrei Alexandrescu wrote:
On 8/29/11 1:39 PM, Timon Gehr wrote:
On 08/29/2011 07:44 PM, Martin Nowak wrote:
On Mon, 29 Aug 2011 18:55:56 +0200, Andrej Mitrovic
wrote:
Oh man wouldn't it be cool if we could use this syntax like this:
void test(R1:isInputRange, R2:isF
You can read about it here,
http://www.gamasutra.com/view/feature/6470/a_conversation_with_bill_budge.php?print=1
On 8/17/11 6:12 PM, David Nadlinger wrote:
Now that Lars Kyllingstad's new and improved std.path has passed the
vote – congratulations, Lars! –, and Jose Armando Garcia, the author of
the proposed logging module, is currently not available, the etc.curl
module by Jonas Drewsen is at the front of
On 8/29/11 1:39 PM, Timon Gehr wrote:
On 08/29/2011 07:44 PM, Martin Nowak wrote:
On Mon, 29 Aug 2011 18:55:56 +0200, Andrej Mitrovic
wrote:
Oh man wouldn't it be cool if we could use this syntax like this:
void test(R1:isInputRange, R2:isForwardRange)(R1 r1, R2 r2) {}
I'm not sure how that
On 2011-08-29 11:44:46 +, Robert Clipsham said:
Hey all,
For those of you that doesn't know, Objective-C primarily uses
reference counting to manage memory. With the latest releases of clang,
it also supports automatic reference counting, whereby the compiler
automatically inserts retai
On 08/29/2011 07:44 PM, Martin Nowak wrote:
On Mon, 29 Aug 2011 18:55:56 +0200, Andrej Mitrovic
wrote:
Oh man wouldn't it be cool if we could use this syntax like this:
void test(R1:isInputRange, R2:isForwardRange)(R1 r1, R2 r2) {}
I'm not sure how that would work with multiple constraints o
Jonathan M Davis:
> Yeah. I don't know why it's allowed. I think that C++, Java, and C# all allow
> it too, but I've always thought that it was a bad idea in all of those
> languages.
> ...
> but it strikes me as very lax to allow a static
> method to be called with an instance. That's definite
On Monday, August 29, 2011 07:44 Steven Schveighoffer wrote:
> My opinion is that static methods should *not* be callable from an
> instance, you should need typeof(instance).staticMethod. The current
> allowance is misleading.
Yeah. I don't know why it's allowed. I think that C++, Java, and C# al
On Mon, 29 Aug 2011 18:55:56 +0200, Andrej Mitrovic
wrote:
Oh man wouldn't it be cool if we could use this syntax like this:
void test(R1:isInputRange, R2:isForwardRange)(R1 r1, R2 r2) {}
I'm not sure how that would work with multiple constraints or
constraints that need comparisons, e.g. E
Oh man wouldn't it be cool if we could use this syntax like this:
void test(R1:isInputRange, R2:isForwardRange)(R1 r1, R2 r2) {}
I'm not sure how that would work with multiple constraints or
constraints that need comparisons, e.g. ElementType:
void test(R1:isInputRange && ElementType == int, R2:
On 08/29/2011 06:30 PM, Alex Rønne Petersen wrote:
On 29-08-2011 18:15, Andrej Mitrovic wrote:
On 8/29/11, kennytm wrote:
On the pattern matching syntax for templates in the comments -- Sigh,
the
spec gotta advertise this valid syntax in the operator overloading page
more:
Foo opBinary(string
On 29-08-2011 18:15, Andrej Mitrovic wrote:
On 8/29/11, kennytm wrote:
On the pattern matching syntax for templates in the comments -- Sigh, the
spec gotta advertise this valid syntax in the operator overloading page
more:
Foo opBinary(string op:"+")(...) { ... }
Wow I didn't know abou
On 8/29/11, kennytm wrote:
> On the pattern matching syntax for templates in the comments -- Sigh, the
> spec gotta advertise this valid syntax in the operator overloading page
> more:
>
> Foo opBinary(string op:"+")(...) { ... }
>
Wow I didn't know about this. So now I can do this:
enum Foo
On 24-08-2011 19:52, Andrei Alexandrescu wrote:
On 8/24/11 9:39 AM, Alex Rønne Petersen wrote:
On 24-08-2011 16:47, Andrei Alexandrescu wrote:
On 8/24/11 6:58 AM, Timon Gehr wrote:
So, basically interfaces are the only place in D?/DMD where you can
even
specify contracts without a function bod
On 29-08-2011 16:44, Steven Schveighoffer wrote:
My opinion is that static methods should *not* be callable from an
instance, you should need typeof(instance).staticMethod. The current
allowance is misleading.
+1.
- Alex
On Mon, Aug 29, 2011 at 8:50 AM, Vijay Nayar wrote:
> On Sat, 27 Aug 2011 16:40:39 +0300, Radu Toev wrote:
>
> There are two possibilities I can imagine:
> A. The phobos2 library was somehow incomplete or not built correctly.
> To check this possibility, use the 'nm' command and search for the
"Steven Schveighoffer" wrote in message
news:op.v0zckubyeav7ka@localhost.localdomain...
>
> My opinion is that static methods should *not* be callable from an
> instance, you should need typeof(instance).staticMethod. The current
> allowance is misleading.
>
> This should solve some of the iss
On Mon, 29 Aug 2011 10:25:18 -0400, Jacob Carlborg wrote:
On 2011-08-29 16:10, Daniel Murphy wrote:
"Jacob Carlborg" wrote in message
news:j3fi1u$1uge$1...@digitalmars.com...
I just got and idea, what about allowing to overload methods based on
if
they're static or not.
From my list of
On 2011-08-29 16:10, Daniel Murphy wrote:
"Jacob Carlborg" wrote in message
news:j3fi1u$1uge$1...@digitalmars.com...
I just got and idea, what about allowing to overload methods based on if
they're static or not.
From my list of 'Andrei' bugs:
http://d.puremagic.com/issues/show_bug.cgi?id=33
"Jacob Carlborg" wrote in message
news:j3fi1u$1uge$1...@digitalmars.com...
>I just got and idea, what about allowing to overload methods based on if
>they're static or not.
>From my list of 'Andrei' bugs:
http://d.puremagic.com/issues/show_bug.cgi?id=3345
It sounds like a good idea, but what a
On Sat, 27 Aug 2011 16:40:39 +0300, Radu Toev wrote:
There are two possibilities I can imagine:
A. The phobos2 library was somehow incomplete or not built correctly.
To check this possibility, use the 'nm' command and search for the
missing symbol. I used the Ubuntu standard dmd package, so
On 25/08/2011 02:41, Michel Fortin wrote:
bool frontEquals(R, V)(R range, V value)
{
if (range.empty)
return false;
else
return range.front == value;
}
This will work fine with most ranges, but if you encounter an infinite range
(with empty
defined as "enum empty = fals
Hey all,
For those of you that doesn't know, Objective-C primarily uses reference
counting to manage memory. With the latest releases of clang, it also
supports automatic reference counting, whereby the compiler
automatically inserts retain/release messages ("calls" if you don't know
Obj-C) i
One of the comments written by Walter:
>Few programmers stuff so much on one line that it becomes difficult picking
>out the error.<
If you write D code in functional-style then lines of code often become quite
long.
Bye,
bearophile
I just got and idea, what about allowing to overload methods based on if
they're static or not. This would allow the following code:
class Foo
{
void bar () { writeln("bar"); }
static void bar () { writeln("static bar"); }
}
Foo.bar; // would print "static bar"
auto foo = new Foo;
fo
63 matches
Mail list logo
