Andrei Alexandrescu wrote:
> Rainer Deyke wrote:
>> You need some syntactic way to distinguish the contained value from the
>> container. Using "alias this" seems messy here. Optional!Optional!T is
>> both valid and likely to occur.
>
> Interesting. I wonder whether it's better to fold Optional!
On Thu, Sep 3, 2009 at 1:49 AM, Nick Sabalausky wrote:
> And if anyone knows how to edit a system-settings text file without
> dropping to the command-line and doing "sudo gedit blahfile &" (and without
> having to start out with "sudo pwd" or "sudo echo" just so the "sudo gedit
> &" does something
"Andrei Alexandrescu" wrote in message
news:h78lf7$7a...@digitalmars.com...
> Lars T. Kyllingstad wrote:
>>
>> Good luck! Always afraid of unfamilar territory, I first tried Linux in a
>> dual-boot setup too, several years ago. I think it took about a week
>> before I deleted the Windows partit
Jarrett Billingsley wrote:
> ...
>
> void foob(T: Ret function(Args), Ret, Args...)(T func)
> {
> pragma(msg, ParameterTupleOf!(T).stringof);
> static void wtf(ParameterTupleOf!(T) args) {}
> pragma(msg, ParameterTupleOf!(T).stringof);
> }
>
> void blah(int, ref float) {}
>
>
Jarrett Billingsley wrote:
On Wed, Sep 2, 2009 at 9:45 AM, Andrei
Alexandrescu wrote:
Jarrett Billingsley wrote:
Well repeat should probably always take a delegate since most likely,
you're going to be passing it a lambda. However I agree that it would
be very, very nice to be able to make APIs
"language_fan" wrote in message
news:h73t5v$22a...@digitalmars.com...
> Thu, 20 Aug 2009 16:11:14 -0400, Nick Sabalausky thusly wrote:
>
>> "Lutger" wrote in message
>> news:h6j06p$24v...@digitalmars.com...
>>>
>>> - how the distro deals with patented and closed source software. (mp3,
>>> dvd,
>
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
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 looks and feels much like a T,
except that it supports a function
Andrei Alexandrescu wrote:
> That's why I want to add no member functions to Optional. The test for
> null will be a free function.
I don't you can implement Optional without at least one (possibly
private) data member. Does 'alias this' shadow private data members?
--
Rainer Deyke - rain...@e
Andrei Alexandrescu wrote:
> 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 looks and feels much like a T,
> except that it supports a function
>
> bool isNull
On Wed, Sep 2, 2009 at 8:20 PM, Jeremie Pelletier wrote:
> 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
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
Andrei Alexandrescu:
> bool isNull(T)(Optional!T value);
> Am I on the right track? If so, what is the name you'd prefer for this
> artifact?
It looks good and simple enough. The name may be "Nullable" or "Maybe" or
something like that. This looks like a good use case of the alias this" feature
Jeremie Pelletier Wrote:
> There's a huge difference between complex code and long code, especially in
> compiled languages. Those 8 lines in your code are not convenient in that you
> don't get what they do on first sight. Declaring your things separately and
> then registering the closures to
Danny Wilson wrote:
Op Wed, 02 Sep 2009 22:55:53 +0200 schreef Andrei Alexandrescu
:
So if pointers wouldn't be considered evil, Maybe!T* would suffice?
Can someone point me out what the big difference is between ref and
simply disallowing pointer arithmitic? Is it marketing?
Ref means
Op Wed, 02 Sep 2009 22:55:53 +0200 schreef Andrei Alexandrescu
:
So if pointers wouldn't be considered evil, Maybe!T* would suffice?
Can someone point me out what the big difference is between ref and
simply disallowing pointer arithmitic? Is it marketing?
Ref means lvalue of type T.
On Wed, Sep 2, 2009 at 4:20 PM, Andrei
Alexandrescu wrote:
> Great. Now, before we get all jolly about Maybe, let me point out that we
> also need the "ref" corresponding type. And OptionalRef and NullableRef may
> sound better to some than MaybeRef.
But reference types already are nullable. Unles
On Wed, Sep 2, 2009 at 4:53 PM, Nick Sabalausky wrote:
>> void foo(bool delegate() dg) {
>> dg();
>> }
>> foo({return true;});
>>
>
> Sure, when there's no parameters (...does that work in D1, or just D2?...),
> but even then, I still always end up going though a process like this when
> definin
Danny Wilson wrote:
Op Wed, 02 Sep 2009 22:20:04 +0200 schreef Andrei Alexandrescu
:
Jarrett Billingsley wrote:
On Wed, Sep 2, 2009 at 4:13 PM, Simen
Kjaeraas wrote:
Danny Wilson wrote:
Op Wed, 02 Sep 2009 21:39:28 +0200 schreef Andrei Alexandrescu
:
I plan to add a Nullable struct to Ph
"Jeremie Pelletier" wrote in message
news:h7m6nb$2k8...@digitalmars.com...
>
> The only valid syntax is up there,
Yea, but which one? ;)
> I almost only use delegates in D, since it allows functions pointers,
> delegates, closures and nested functions to be passed. Function pointers
> only a
grauzone wrote:
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. Th
Danny Wilson wrote:
So if pointers wouldn't be considered evil, Maybe!T* would suffice?
Can someone point me out what the big difference is between ref and
simply disallowing pointer arithmitic? Is it marketing?
Well, for one, we don't want to disallow pointer arithmetic. Then, we
intro
"Jarrett Billingsley" wrote in message
news:mailman.30.1251909028.20261.digitalmar...@puremagic.com...
>
>I'd really, really like to replace your entire module with this:
>
>Ret delegate(Args) toDg(T: Ret function(Args), Ret, Args...)(T func)
>{
>[snip]
>}
>
>But I can't. :C
Yea. But even then,
Op Wed, 02 Sep 2009 22:20:04 +0200 schreef Andrei Alexandrescu
:
Jarrett Billingsley wrote:
On Wed, Sep 2, 2009 at 4:13 PM, Simen Kjaeraas
wrote:
Danny Wilson wrote:
Op Wed, 02 Sep 2009 21:39:28 +0200 schreef Andrei Alexandrescu
:
I plan to add a Nullable struct to Phobos (akin to C#'s
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
Michiel Helvensteijn wrote:
> Basically, any function that reads i may not be called before i is
> declared, nor in i's initialization. Of course, in reality, it depends on
> the control flow within the function. But that's holy grail stuff. So:
> conservatively.
Oh, you may also not take a deleg
Jarrett Billingsley wrote:
> It wouldn't even be that difficult. Basically if you treat
> forward-referenced nested functions as a sort of goto, the same rules
> should apply: a call to a nested function may not skip the
> initialization of any variables it depends on. When i's initializer is
> ev
"Jarrett Billingsley" wrote in message
news:mailman.32.1251920615.20261.digitalmar...@puremagic.com...
> On Wed, Sep 2, 2009 at 3:29 PM, Don wrote:
>> Michiel Helvensteijn wrote:
>>>
>>> Rainer Deyke wrote:
>>>
That can lead to subtle problems in the case of functions:
int i = f();
Jarrett Billingsley wrote:
On Wed, Sep 2, 2009 at 4:13 PM, Simen Kjaeraas wrote:
Danny Wilson wrote:
Op Wed, 02 Sep 2009 21:39:28 +0200 schreef Andrei Alexandrescu
:
I plan to add a Nullable struct to Phobos (akin to C#'s Nullable, Boost's
Optional).
Apparently a good design is to define O
On Wed, Sep 2, 2009 at 4:13 PM, Simen Kjaeraas wrote:
> Danny Wilson wrote:
>
>> Op Wed, 02 Sep 2009 21:39:28 +0200 schreef Andrei Alexandrescu
>> :
>>
>>> I plan to add a Nullable struct to Phobos (akin to C#'s Nullable, Boost's
>>> Optional).
>>>
>>> Apparently a good design is to define Optiona
"Walter Bright" wrote in message
news:h7mch9$l5...@digitalmars.com...
> Mattias Holm wrote:
>> Walter Bright wrote:
>>> S. wrote:
>>> I find it strange that people are continuing to reinvent nested
>>> functions in ugly ways.
>>
>> The blocks are not nested functions, they are more like closures
"Nick Sabalausky" wrote in message
news:h7mjfe$2p0...@digitalmars.com...
> "Walter Bright" wrote in message
> news:h7mch9$l5...@digitalmars.com...
>
> BTW, if you think the "nested funcs" most languages have are bad, you
> should see the Haxe version:
>
> class EverythingMustBeInAClass_Natch
>
Danny Wilson wrote:
Op Wed, 02 Sep 2009 21:39:28 +0200 schreef Andrei Alexandrescu
:
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 t
Op Wed, 02 Sep 2009 21:39:28 +0200 schreef Andrei Alexandrescu
:
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
On Wed, Sep 2, 2009 at 3:29 PM, Don wrote:
> Michiel Helvensteijn wrote:
>>
>> Rainer Deyke wrote:
>>
I still find it silly that it was built that way. Seems to me you should
be able to forward-reference *any* symbol that has a value that can't
change over its lifetime. Functions, co
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 looks and feels much like a
Michiel Helvensteijn wrote:
Rainer Deyke wrote:
I still find it silly that it was built that way. Seems to me you should
be able to forward-reference *any* symbol that has a value that can't
change over its lifetime. Functions, const/immutable vars, typedefs,
classes, etc.
That can lead to sub
grauzone wrote:
It has been a GCC extension for a long time:
http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65
Which further makes it a mystery why this has to be badly reinvented.
(But note that the gcc extension has the same problem D1 has with them;
the closures don't survive the
Mattias Holm, el 2 de septiembre a las 18:08 me escribiste:
> Leandro Lucarella wrote:
>
> >GCC support them as an extension to C for ages too.
>
> True for nested functions but nested functions are not blocks.
I know, you removed the context of my response, I was refering to nested
functions..
Rainer Deyke wrote:
>> I still find it silly that it was built that way. Seems to me you should
>> be able to forward-reference *any* symbol that has a value that can't
>> change over its lifetime. Functions, const/immutable vars, typedefs,
>> classes, etc.
>
> That can lead to subtle problems in
Michiel Helvensteijn wrote:
> I still find it silly that it was built that way. Seems to me you should be
> able to forward-reference *any* symbol that has a value that can't change
> over its lifetime. Functions, const/immutable vars, typedefs, classes, etc.
That can lead to subtle problems in th
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
Mattias Holm wrote:
Walter Bright wrote:
S. wrote:
I find it strange that people are continuing to reinvent nested
functions in ugly ways.
The blocks are not nested functions, they are more like closures.
Nested functions do closures in a straightforward way, so by leaving off
nested funct
On Wed, Sep 2, 2009 at 9:45 AM, Andrei
Alexandrescu wrote:
> Jarrett Billingsley wrote:
>>
>> Well repeat should probably always take a delegate since most likely,
>> you're going to be passing it a lambda. However I agree that it would
>> be very, very nice to be able to make APIs take just delega
Nick Sabalausky Wrote:
> "Jeremie Pelletier" wrote in message
> news:h7h5i1$5m...@digitalmars.com...
> >
> > While D is not the first place I see closures and nested functions, it is
> > the first language I come across that blends delegates, closures and
> > nested functions in a simple, eleg
On Wed, Sep 2, 2009 at 9:49 AM, Daniel Keep wrote:
>
> Jarrett Billingsley wrote:
>> Well repeat should probably always take a delegate since most likely,
>> you're going to be passing it a lambda. However I agree that it would
>> be very, very nice to be able to make APIs take just delegates and
>
Michel Fortin Wrote:
> On 2009-09-02 00:27:46 -0400, S. said:
>
> > Been awhile since I posted.
> >
> > I was wondering what other people thought about this addition to C++ by
> > Apple. Heh.
> >
> > http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/10
>
> I don't find the syn
Leandro Lucarella wrote:
GCC support them as an extension to C for ages too.
True for nested functions but nested functions are not blocks.
typedef void (*foo_t)(void);
foo_t getSomeFunc()
{
int x = 4;
void bar(void) {
printf("%d\n", x);
}
return
Martin Franhaufer, el 2 de septiembre a las 03:49 me escribiste:
> Walter Bright Wrote:
>
> > Nick Sabalausky wrote:
> > > "Walter Bright" wrote in message
> > > news:h7l32i$e...@digitalmars.com...
> > >> S. wrote:
> > >>> I was wondering what other people thought about this addition to C++ by
Walter Bright wrote:
S. wrote:
I find it strange that people are continuing to reinvent nested
functions in ugly ways.
The blocks are not nested functions, they are more like closures. There
are some block copy functions that move a block to the heap (including
the captured variables).
Nes
Jarrett Billingsley wrote:
> Well repeat should probably always take a delegate since most likely,
> you're going to be passing it a lambda. However I agree that it would
> be very, very nice to be able to make APIs take just delegates and
> allow functions to be implicitly cast to them. You can a
Jarrett Billingsley wrote:
Well repeat should probably always take a delegate since most likely,
you're going to be passing it a lambda. However I agree that it would
be very, very nice to be able to make APIs take just delegates and
allow functions to be implicitly cast to them. You can already
On Wed, Sep 2, 2009 at 6:07 AM, Nick Sabalausky wrote:
> Umm, yea. If you don't already know what I'm getting at with that, then...
> Quick! For each of these, valid or invalid?:
> // D
> void repeat(int n, void delegate(int i) dg)
> {
> foreach(int i; 0..n)
> d
Nick Sabalausky wrote:
> "Jeremie Pelletier" wrote in message
> news:h7h5i1$5m...@digitalmars.com...
>>
>> While D is not the first place I see closures and nested functions, it is
>> the first language I come across that blends delegates, closures and
>> nested functions in a simple, elegant and
If the loop index "i" isn't necessary, you can use simpler code:
import std.stdio: writeln;
void repeat(TF)(int n, lazy TF callme) {
foreach (i; 0 .. n)
callme();
}
void main() {
repeat(5, writeln("hi"));
}
Bye,
bearophile
Nick Sabalausky:
> Quick! For each of these, valid or invalid?:
I may like this one:
import std.stdio: writeln;
import d.templates: IsCallable;
void repeat(TyCall)(int n, TyCall callme) if (IsCallable!TyCall) {
foreach (i; 0 .. n)
callme(i);
}
void main() {
repeat(5, (int i){ wr
Wed, 02 Sep 2009 13:35:05 +0200, Michiel Helvensteijn thusly wrote:
> language_fan wrote:
>
>>> I agree it would be better to allow forward references for nested
>>> functions, I just wished to point out that the current behavior is not
>>> a bug, it was built that way.
>>
>> That's great news a
Mon, 31 Aug 2009 14:42:09 -0400, Jeremie Pelletier thusly wrote:
> I agree with Walter here. While D is not the first place I see closures
> and nested functions, it is the first language I come across that blends
> delegates, closures and nested functions in a simple, elegant and
> intuitive mann
language_fan wrote:
>> I agree it would be better to allow forward references for nested
>> functions, I just wished to point out that the current behavior is not a
>> bug, it was built that way.
>
> That's great news actually. It might even mean that this might change
> some day.
I still find i
Mon, 31 Aug 2009 13:17:11 -0700, Walter Bright thusly wrote:
> I agree it would be better to allow forward references for nested
> functions, I just wished to point out that the current behavior is not a
> bug, it was built that way.
That's great news actually. It might even mean that this might
Wed, 02 Sep 2009 10:28:58 +0200, downs thusly wrote:
> Robert Fraser wrote:
>> downs wrote:
>>> foo.betweens("src=\"", "\"") /select/ (string s) { return
>>> s.find(criteria) != -1; }
>>
>> Heh, I love that infix expression syntax. Too abd it ends up with a
>> completely useless wrapper stru
"Walter Bright" wrote in message
news:h7l6hu$a7...@digitalmars.com...
> Nick Sabalausky wrote:
>> "Walter Bright" wrote in message
>> news:h7l32i$e...@digitalmars.com...
>>> S. wrote:
I was wondering what other people thought about this addition to C++ by
Apple. Heh.
http
"Jeremie Pelletier" wrote in message
news:h7h5i1$5m...@digitalmars.com...
>
> While D is not the first place I see closures and nested functions, it is
> the first language I come across that blends delegates, closures and
> nested functions in a simple, elegant and intuitive manner.
>
I almos
Martin Franhaufer wrote:
Yes - Pascal has been doing that for years :-)
I know, I learned it from Pascal.
Robert Fraser wrote:
> downs wrote:
>> foo.betweens("src=\"", "\"") /select/ (string s) { return
>> s.find(criteria) != -1; }
>
> Heh, I love that infix expression syntax. Too abd it ends up with a
> completely useless wrapper struct & 2 function calls, but hopefully LDC
> can inline that out
Walter Bright Wrote:
> Nick Sabalausky wrote:
> > "Walter Bright" wrote in message
> > news:h7l32i$e...@digitalmars.com...
> >> S. wrote:
> >>> I was wondering what other people thought about this addition to C++ by
> >>> Apple. Heh.
> >>>
> >>> http://arstechnica.com/apple/reviews/2009/08/ma
On 2009-09-02 00:27:46 -0400, S. said:
Been awhile since I posted.
I was wondering what other people thought about this addition to C++ by
Apple. Heh.
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/10
I don't find the syntax that ugly. And I'd say the feature is at its
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 the materials for the
C
Nick Sabalausky wrote:
"Walter Bright" wrote in message
news:h7l32i$e...@digitalmars.com...
S. wrote:
I was wondering what other people thought about this addition to C++ by
Apple. Heh.
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/10
I find it strange that people are co
68 matches
Mail list logo
