https://github.com/D-Programming-Language/phobos/pull/94
Discuss!
Andrei
I like how your proposal is already a pull request.
I'm not too fond of this workaround:
bool state;
getopt(
args,
"state", &state,
);
auto line = getLine(cast(Flag!"KeepTerminator")state);
Will getopt know how to use Flags? What about std.conv.to?
std.format/write will have to kno
On 6/10/11 11:45 AM, Andrej Mitrovic wrote:
I like how your proposal is already a pull request.
I'm not too fond of this workaround:
bool state;
getopt(
args,
"state",&state,
);
auto line = getLine(cast(Flag!"KeepTerminator")state);
Will getopt know how to use Flags? What about std.c
*notice
On 6/10/11, Andrei Alexandrescu wrote:
> Without the cast, writeln prints "yes" or "no", which may be desirable.
> If you want to print the bool, you can say
>
> writeln(keepTerminator == Flag!"KeepTerminator".yes);
>
> or
>
> writeln(!!keepTerminator);
>
Oh, maybe this was already incorporated i
On 10/06/2011 17:15, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/phobos/pull/94
Discuss!
Andrei
I really *really* don't like this. It's ugly and verbose, and a pathetic
work around for the lack of named parameters. Either support named
parameters or not, don't have
On Jun 11, 11 01:41, Andrej Mitrovic wrote:
On 6/10/11, Andrei Alexandrescu wrote:
Without the cast, writeln prints "yes" or "no", which may be desirable.
If you want to print the bool, you can say
writeln(keepTerminator == Flag!"KeepTerminator".yes);
or
writeln(!!keepTerminator);
Oh, may
On Jun 11, 11 01:42, Robert Clipsham wrote:
On 10/06/2011 17:15, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/phobos/pull/94
Discuss!
Andrei
I really *really* don't like this. It's ugly and verbose, and a pathetic
work around for the lack of named parameters. Either s
On 6/10/11 12:42 PM, Robert Clipsham wrote:
On 10/06/2011 17:15, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/phobos/pull/94
Discuss!
Andrei
I really *really* don't like this. It's ugly and verbose, and a pathetic
work around for the lack of named parameters. Either s
On 2011-06-10 10:57, KennyTM~ wrote:
> On Jun 11, 11 01:42, Robert Clipsham wrote:
> > On 10/06/2011 17:15, Andrei Alexandrescu wrote:
> >> https://github.com/D-Programming-Language/phobos/pull/94
> >>
> >> Discuss!
> >>
> >> Andrei
> >
> > I really *really* don't like this. It's ugly and verbos
On 10/06/2011 19:06, Andrei Alexandrescu wrote:
On 6/10/11 12:42 PM, Robert Clipsham wrote:
On 10/06/2011 17:15, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/phobos/pull/94
Discuss!
Andrei
I really *really* don't like this. It's ugly and verbose, and a pathetic
work
On 2011-06-10 14:52:53 -0400, Robert Clipsham said:
On 10/06/2011 19:06, Andrei Alexandrescu wrote:
Ugly is in the eye of the beholder, but I fail to see how the added
punctuation makes Flag!"param".yes significantly more verbose than param
: true.
foo(param: true, otherParam: false);
foo(Fl
On 2011-06-10 09:15, Andrei Alexandrescu wrote:
> https://github.com/D-Programming-Language/phobos/pull/94
>
> Discuss!
I do have to admit that as much as I hate the idea of named parameters, this
particular proposal certainly seems to be an argument in favor of adding them,
which would tend to
On Jun 11, 11 03:30, Jonathan M Davis wrote:
On 2011-06-10 09:15, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/phobos/pull/94
Discuss!
I do have to admit that as much as I hate the idea of named parameters, this
particular proposal certainly seems to be an argument in
On Jun 11, 11 02:06, Andrei Alexandrescu wrote:
On 6/10/11 12:42 PM, Robert Clipsham wrote:
On 10/06/2011 17:15, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/phobos/pull/94
Discuss!
Andrei
I really *really* don't like this. It's ugly and verbose, and a pathetic
work
On 2011-06-10 12:33, KennyTM~ wrote:
> On Jun 11, 11 03:30, Jonathan M Davis wrote:
> > On 2011-06-10 09:15, Andrei Alexandrescu wrote:
> >> https://github.com/D-Programming-Language/phobos/pull/94
> >>
> >> Discuss!
> >
> > I do have to admit that as much as I hate the idea of named parameters,
On Jun 11, 11 03:40, Jonathan M Davis wrote:
On 2011-06-10 12:33, KennyTM~ wrote:
On Jun 11, 11 03:30, Jonathan M Davis wrote:
On 2011-06-10 09:15, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/phobos/pull/94
Discuss!
I do have to admit that as much as I hate the idea
"Michel Fortin" wrote in message
news:istqjn$2jld$1...@digitalmars.com...
> On 2011-06-10 14:52:53 -0400, Robert Clipsham
> said:
>
>> On 10/06/2011 19:06, Andrei Alexandrescu wrote:
>>> Ugly is in the eye of the beholder, but I fail to see how the added
>>> punctuation makes Flag!"param".yes s
On 2011-06-10 12:47, KennyTM~ wrote:
> On Jun 11, 11 03:40, Jonathan M Davis wrote:
> > On 2011-06-10 12:33, KennyTM~ wrote:
> >> On Jun 11, 11 03:30, Jonathan M Davis wrote:
> >>> On 2011-06-10 09:15, Andrei Alexandrescu wrote:
> https://github.com/D-Programming-Language/phobos/pull/94
>
On 6/10/11 1:52 PM, Robert Clipsham wrote:
On 10/06/2011 19:06, Andrei Alexandrescu wrote:
On 6/10/11 12:42 PM, Robert Clipsham wrote:
On 10/06/2011 17:15, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/phobos/pull/94
Discuss!
Andrei
I really *really* don't like this.
On 6/10/11 2:12 PM, Michel Fortin wrote:
On 2011-06-10 14:52:53 -0400, Robert Clipsham
said:
On 10/06/2011 19:06, Andrei Alexandrescu wrote:
Ugly is in the eye of the beholder, but I fail to see how the added
punctuation makes Flag!"param".yes significantly more verbose than param
: true.
f
On 6/10/11 9:47 PM, Nick Sabalausky wrote:
I completely agree with Robert and Michel on all the points they've raised.
Flag is admittedly a great example of the power of D's templates. And it's
admittedly a very clever hack to get around *some* of the limitations of not
having named parameters...
On 6/10/11 2:30 PM, Jonathan M Davis wrote:
On 2011-06-10 09:15, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/phobos/pull/94
Discuss!
I do have to admit that as much as I hate the idea of named parameters, this
particular proposal certainly seems to be an argument in f
2011/6/10 Andrei Alexandrescu :
> On 6/10/11 1:52 PM, Robert Clipsham wrote:
>>
>> On 10/06/2011 19:06, Andrei Alexandrescu wrote:
>>>
>>> On 6/10/11 12:42 PM, Robert Clipsham wrote:
On 10/06/2011 17:15, Andrei Alexandrescu wrote:
>
> https://github.com/D-Programming-Language/phob
"Andrei Alexandrescu" wrote in message
news:isttf6$2oub$1...@digitalmars.com...
> On 6/10/11 1:52 PM, Robert Clipsham wrote:
>> On 10/06/2011 19:06, Andrei Alexandrescu wrote:
>>> On 6/10/11 12:42 PM, Robert Clipsham wrote:
On 10/06/2011 17:15, Andrei Alexandrescu wrote:
> https://github
On 2011-06-10 16:10:51 -0400, Andrei Alexandrescu
said:
On 6/10/11 2:12 PM, Michel Fortin wrote:
I have to say I totally agree with Robert.
I agree with the need for a way to name parameters, but instantiating a
pseudo-boolean type from a template for each function parameter is worse
than th
"Nick Sabalausky" wrote in message
news:istv62$2skn$1...@digitalmars.com...
> "Andrei Alexandrescu" wrote in message
> news:isttf6$2oub$1...@digitalmars.com...
>> On 6/10/11 1:52 PM, Robert Clipsham wrote:
>>>
>>> foo(param: true, otherParam: false);
>>> foo(Flag!"param".yes, Flag!"otherParam".
"Andrei Alexandrescu" wrote in message
news:istulq$2rjc$1...@digitalmars.com...
> On 6/10/11 2:30 PM, Jonathan M Davis wrote:
>> On 2011-06-10 09:15, Andrei Alexandrescu wrote:
>>> https://github.com/D-Programming-Language/phobos/pull/94
>>>
>>> Discuss!
>>
>> I do have to admit that as much as I
On 6/10/11 3:30 PM, Nick Sabalausky wrote:
I really see Flag more as a way to try to rationalize avoiding adding named
parameters to the language.
There are fights that I believe are important and others that I think
are less so. I find name parameters nice to have but more in the second
cate
Andrei:
> We should be much more restrained than this discussion suggests. Any and
> all programming languages have limitations. This, coupled with the
> former point, leads to the fact that at some point you MUST look into
> doing within the language something that could be done nicer if you g
On 6/10/11 3:34 PM, Michel Fortin wrote:
On 2011-06-10 16:10:51 -0400, Andrei Alexandrescu
said:
On 6/10/11 2:12 PM, Michel Fortin wrote:
I have to say I totally agree with Robert.
I agree with the need for a way to name parameters, but instantiating a
pseudo-boolean type from a template for
On 2011-06-10 13:36, Nick Sabalausky wrote:
> "Nick Sabalausky" wrote in message
> news:istv62$2skn$1...@digitalmars.com...
>
> > "Andrei Alexandrescu" wrote in message
> > news:isttf6$2oub$1...@digitalmars.com...
> >
> >> On 6/10/11 1:52 PM, Robert Clipsham wrote:
> >>> foo(param: true, otherP
On 6/10/11 3:36 PM, Nick Sabalausky wrote:
"Nick Sabalausky" wrote in message
news:istv62$2skn$1...@digitalmars.com...
"Andrei Alexandrescu" wrote in message
news:isttf6$2oub$1...@digitalmars.com...
On 6/10/11 1:52 PM, Robert Clipsham wrote:
foo(param: true, otherParam: false);
foo(Flag!"pa
Nick Sabalausky wrote:
> "Nick Sabalausky" wrote in message
> news:istv62$2skn$1...@digitalmars.com...
>> "Andrei Alexandrescu" wrote in message
>> news:isttf6$2oub$1...@digitalmars.com...
>>> On 6/10/11 1:52 PM, Robert Clipsham wrote:
foo(param: true, otherParam: false);
foo(Flag
Andrei:
> I don't want a universal thing, I want to solve a simple problem: there
> are 7 yes/no enums in Phobos, and probably some more to come. Flag
> solves that problem in a reasonable way. This is pretty much it.
I didn't understand this well at first. Thank you for explaining again.
Bye,
On 6/10/11, Lutger Blijdestijn wrote:
> Changing a name will now break client code.
The flag template suffers from the same issue.
On 6/10/11 4:28 PM, Andrej Mitrovic wrote:
On 6/10/11, Lutger Blijdestijn wrote:
Changing a name will now break client code.
The flag template suffers from the same issue.
Actually, not. The name used with Flag is part of its type. Even in a
separate compilation approach, the type names mu
Andrej Mitrovic wrote:
> On 6/10/11, Lutger Blijdestijn wrote:
>> Changing a name will now break client code.
>
> The flag template suffers from the same issue.
Not strictly, but practically yes. It's also the point of them, exposing
this name in the api. But its *only* for those parameters, w
On 2011-06-10 14:28, Andrej Mitrovic wrote:
> On 6/10/11, Lutger Blijdestijn wrote:
> > Changing a name will now break client code.
>
> The flag template suffers from the same issue.
Not really. There's a big difference between changing the type name and
changing the parameter name. You can fre
"Jonathan M Davis" wrote in message
news:mailman.781.1307734245.14074.digitalmar...@puremagic.com...
> On 2011-06-10 09:15, Andrei Alexandrescu wrote:
>> https://github.com/D-Programming-Language/phobos/pull/94
>>
>> Discuss!
>
> I do have to admit that as much as I hate the idea of named paramet
"Lutger Blijdestijn" wrote in message
news:isu365$2ao$1...@digitalmars.com...
> Andrej Mitrovic wrote:
>
>> On 6/10/11, Lutger Blijdestijn wrote:
>>> Changing a name will now break client code.
>>
>> The flag template suffers from the same issue.
>
> Not strictly, but practically yes. It's also
On 2011-06-10 14:44, Nick Sabalausky wrote:
> "Lutger Blijdestijn" wrote in message
> news:isu365$2ao$1...@digitalmars.com...
>
> > Andrej Mitrovic wrote:
> >> On 6/10/11, Lutger Blijdestijn wrote:
> >>> Changing a name will now break client code.
> >>
> >> The flag template suffers from the sa
"Jonathan M Davis" wrote in message
news:mailman.791.1307742081.14074.digitalmar...@puremagic.com...
> On 2011-06-10 14:28, Andrej Mitrovic wrote:
>> On 6/10/11, Lutger Blijdestijn wrote:
>> > Changing a name will now break client code.
>>
>> The flag template suffers from the same issue.
>
> No
"Andrei Alexandrescu" wrote in message
news:isu15s$30as$1...@digitalmars.com...
> On 6/10/11 3:34 PM, Michel Fortin wrote:
>> If you want something to be used everywhere and it is not an
>> implementation detail, make it part of the language. Implementing what
>> sounds should be a language featu
On Fri, 10 Jun 2011 17:34:34 -0400, Andrei Alexandrescu
wrote:
On 6/10/11 4:28 PM, Andrej Mitrovic wrote:
On 6/10/11, Lutger Blijdestijn wrote:
Changing a name will now break client code.
The flag template suffers from the same issue.
Actually, not. The name used with Flag is part of i
Ignore this: I went to reply, hit the wrong key, and it sent before I got to
type anything... The *real* reply in another post...
"Nick Sabalausky" wrote in message
news:isu4gg$5ff$1...@digitalmars.com...
> "Andrei Alexandrescu" wrote in message
> news:isu15s$30as$1...@digitalmars.com...
>> O
On Jun 11, 11 05:59, Jonathan M Davis wrote:
On 2011-06-10 14:44, Nick Sabalausky wrote:
"Lutger Blijdestijn" wrote in message
news:isu365$2ao$1...@digitalmars.com...
Andrej Mitrovic wrote:
On 6/10/11, Lutger Blijdestijn wrote:
Changing a name will now break client code.
The flag templat
On Fri, 10 Jun 2011 17:59:30 -0400, Jonathan M Davis
wrote:
On 2011-06-10 14:44, Nick Sabalausky wrote:
"Lutger Blijdestijn" wrote in message
news:isu365$2ao$1...@digitalmars.com...
> Andrej Mitrovic wrote:
>> On 6/10/11, Lutger Blijdestijn wrote:
>>> Changing a name will now break client
On Fri, 10 Jun 2011 16:21:59 -0400, Andrei Alexandrescu
wrote:
On 6/10/11 2:30 PM, Jonathan M Davis wrote:
On 2011-06-10 09:15, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/phobos/pull/94
Discuss!
I do have to admit that as much as I hate the idea of named paramet
"Andrei Alexandrescu" wrote in message
news:isu15s$30as$1...@digitalmars.com...
> On 6/10/11 3:34 PM, Michel Fortin wrote:
>> If you want something to be used everywhere and it is not an
>> implementation detail, make it part of the language. Implementing what
>> sounds should be a language featu
"Nick Sabalausky" wrote in message
news:isu5aa$6t0$1...@digitalmars.com...
>
> Now who's digging their heels in and just being stubborn? You *really*
> don't see the problem with "Flag!"param" param"?
>
Erm, I mean "the hiccup with it".
"Jonathan M Davis" wrote in message
news:mailman.793.1307743181.14074.digitalmar...@puremagic.com...
> On 2011-06-10 14:44, Nick Sabalausky wrote:
>> "Lutger Blijdestijn" wrote in message
>> news:isu365$2ao$1...@digitalmars.com...
>>
>> > Andrej Mitrovic wrote:
>> >> On 6/10/11, Lutger Blijdest
On 2011-06-10 17:04:42 -0400, Andrei Alexandrescu
said:
On 6/10/11 3:34 PM, Michel Fortin wrote:
If you want something to be used everywhere and it is not an
implementation detail, make it part of the language. Implementing what
sounds should be a language feature through a template hack and
"Michel Fortin" wrote in message
news:isu5tk$816$1...@digitalmars.com...
>
> I understand it's tiresome to create an enum for every parameter, but
> asking all users to write Flag!"" everywhere is going to be tiresome
> everywhere else, which is hardly an improvement.
>
Excellent point.
> I a
Lutger Blijdestijn:
> Somebody one this newsgroup - maybe it was Don Clugston, also made a good
> point against named parameters: it introduces inflexibility because now the
> names of the parameters of a function become part of the public api.
> Changing a name will now break client code.
Sca
On 6/10/11 5:14 PM, Steven Schveighoffer wrote:
On Fri, 10 Jun 2011 16:21:59 -0400, Andrei Alexandrescu
wrote:
There is general agreement (which includes myself) that a language
feature is nicer than Flag,
Yes.
and that Flag is nicer than the current state of affairs.
No. Flag!"KeepTermin
On 6/10/11 5:53 PM, bearophile wrote:
Lutger Blijdestijn:
Somebody one this newsgroup - maybe it was Don Clugston, also made a good
point against named parameters: it introduces inflexibility because now the
names of the parameters of a function become part of the public api.
Changing a name wi
On 6/10/11 5:25 PM, Michel Fortin wrote:
On 2011-06-10 17:04:42 -0400, Andrei Alexandrescu
said:
On 6/10/11 3:34 PM, Michel Fortin wrote:
If you want something to be used everywhere and it is not an
implementation detail, make it part of the language. Implementing what
sounds should be a lang
On 11.06.2011 0:58, Andrei Alexandrescu wrote:
On 6/10/11 3:30 PM, Nick Sabalausky wrote:
I really see Flag more as a way to try to rationalize avoiding adding
named
parameters to the language.
There are fights that I believe are important and others that I think
are less so. I find name par
On 6/10/11 6:03 PM, Dmitry Olshansky wrote:
On 11.06.2011 0:58, Andrei Alexandrescu wrote:
On 6/10/11 3:30 PM, Nick Sabalausky wrote:
I really see Flag more as a way to try to rationalize avoiding adding
named
parameters to the language.
There are fights that I believe are important and other
On 6/10/11, Andrei Alexandrescu wrote:
> On 6/10/11 4:28 PM, Andrej Mitrovic wrote:
>> On 6/10/11, Lutger Blijdestijn wrote:
>>> Changing a name will now break client code.
>>
>> The flag template suffers from the same issue.
>
> Actually, not. The name used with Flag is part of its type. Even in
Andrei:
> That's good evidence that introducing named parameters would be quite
> involved.
It's also good evidence that Martin Odersky, one of the most intelligent
language designers alive today, is willing to do a lot to support named
arguments in his language :-)
Probably implementing tupl
On 6/11/11, Andrei Alexandrescu wrote:
> Ask, and ye shall receive.
>
> https://github.com/andralex/phobos/commit/801ccc96ce56827cd0d0b608895269bdccba4330
That's much more like it. This whole bikeshedding issue for me was
avoiding the nasty bang quote string unquote shenanigans that look
ugly in
On 6/10/11 6:26 PM, bearophile wrote:
Andrei:
That's good evidence that introducing named parameters would be
quite involved.
It's also good evidence that Martin Odersky, one of the most
intelligent language designers alive today, is willing to do a lot to
support named arguments in his langu
he syntax kludges their former
languages force them to use in their programs. So it's not so strange that
people in this forum have on average a significantly lower tolerance to tricks
like your Flag proposal. In a C++ forum your Flag idea probably is much more
welcome, because compared
On 2011-06-10 15:54, Andrei Alexandrescu wrote:
> On 6/10/11 5:14 PM, Steven Schveighoffer wrote:
> > On Fri, 10 Jun 2011 16:21:59 -0400, Andrei Alexandrescu
> >
> > wrote:
> >> There is general agreement (which includes myself) that a language
> >> feature is nicer than Flag,
> >
> > Yes.
> >
On 2011-06-10 16:46, Andrei Alexandrescu wrote:
> On 6/10/11 6:26 PM, bearophile wrote:
> > Andrei:
> >> That's good evidence that introducing named parameters would be
> >> quite involved.
> >
> > It's also good evidence that Martin Odersky, one of the most
> > intelligent language designers aliv
On 6/10/11 7:09 PM, Jonathan M Davis wrote:
What I want to know is what you want to do with such enums where it's actually
_desirable_ that they be defined separately from use.
I guess if you want such you either define the flag separately or make
it an alias and document the alias. I mean the
s force them to use in their programs.
I'd love to see more evidence to this claim.
So it's not so strange that people in this forum have on average a
significantly lower tolerance to tricks like your Flag proposal. In a
C++ forum your Flag idea probably is much more welcome, because
On 6/10/11 7:09 PM, Jonathan M Davis wrote:
I think that there _are_ features that we need to look at adding in some form
or other (such as conditional attributes) in order to solve current problems
in the language (such as the inability to use many attributes - such as pure
and @safe - with temp
On 2011-06-10 18:57:20 -0400, Andrei Alexandrescu
said:
On 6/10/11 5:25 PM, Michel Fortin wrote:
A hack is something that works even though it's ugly and generally cause
people to call for something better. I'm not opposed to using hacks as
long as they're well-encapsulated and not too fragil
Wait, Walter wants to fix this? IIRC just a few days ago he made a
post on how this would be a bad feature because it hides imports in
arbitrary places. I guess he changed his mind..
Andrei:
> This module won't compile in today's D, but not for a matter of
> principles; it's just a random limitation of the language. (It does work
> if you import from within a class or struct.) You can insert most
> declarations in a scope, so the ones you can't insert are just awkward
> ex
Andrei:
> I'd love to see more evidence to this claim.
Right :-)
> Interesting work became possible after it became clear
> to everyone that the language is now given, so it's time to use what's
> there.
If you want to build stable large frameworks and libraries then having a
"stable" (back
On 6/11/11 3:21 AM, bearophile wrote:
Andrei:
This module won't compile in today's D, but not for a matter of
principles; it's just a random limitation of the language. (It does work
if you import from within a class or struct.) You can insert most
declarations in a scope, so the ones you can't
David Nadlinger:
> At least allowing imports in unittests would be nice though â I
> frequently find myself writing »version (unittest) {}« blocks before the
> actual unit tests just to import some modules not needed during regular
> builds (yeah, I suppose I'm somewhat pedantic about that)
On 6/10/2011 6:15 PM, Andrej Mitrovic wrote:
Wait, Walter wants to fix this? IIRC just a few days ago he made a
post on how this would be a bad feature because it hides imports in
arbitrary places.
I did?
Walter:
> I did?
I don't remember you talking about this topic. But I don't want this feature,
overall I think it will not improve the code. An amoeba is often free to move
in every direction in 2D or more, while an insect has a rigid exoskeleton that
constricts it to move only in few ways. Bu
Function local imports make it easier to reason about the code
which is of slight importance. The big thing I'd like though is
using it with mixins.
In my cgi.d, there's a mixin main that depends on std.string being
available inside the mixed in function.
Currently, I use a public import of std.s
On 6/11/11, Walter Bright wrote:
> On 6/10/2011 6:15 PM, Andrej Mitrovic wrote:
>> Wait, Walter wants to fix this? IIRC just a few days ago he made a
>> post on how this would be a bad feature because it hides imports in
>> arbitrary places.
>
> I did?
>
Hmm. It might have been a bug in the matri
On 6/11/11, bearophile wrote:
> But I don't want this
> feature, overall I think it will not improve the code.
I've found someone that contradicts you:
http://www.digitalmars.com/d/archives/digitalmars/D/Function-local_imports_109317.html
On 6/10/2011 6:21 PM, bearophile wrote:
You are allowed to import modules inside functions in Python too (there is a
just a minor restriction), but I have never asked for this feature in D
because this feature has a cost too. Putting all imports at the top of the
module is more tidy, it allows th
On 6/10/11 8:08 PM, Michel Fortin wrote:
On 2011-06-10 18:57:20 -0400, Andrei Alexandrescu
said:
On 6/10/11 5:25 PM, Michel Fortin wrote:
A hack is something that works even though it's ugly and generally cause
people to call for something better. I'm not opposed to using hacks as
long as the
On 6/10/11 8:21 PM, bearophile wrote:
Andrei:
This module won't compile in today's D, but not for a matter of
principles; it's just a random limitation of the language. (It does work
if you import from within a class or struct.) You can insert most
declarations in a scope, so the ones you can't
On 6/10/11 8:31 PM, bearophile wrote:
Andrei:
I'd love to see more evidence to this claim.
Right :-)
Interesting work became possible after it became clear to everyone
that the language is now given, so it's time to use what's there.
If you want to build stable large frameworks and libra
On 6/10/11 8:51 PM, Andrej Mitrovic wrote:
On 6/11/11, bearophile wrote:
But I don't want this
feature, overall I think it will not improve the code.
I've found someone that contradicts you:
http://www.digitalmars.com/d/archives/digitalmars/D/Function-local_imports_109317.html
Wow.
Andrei
On 6/10/11 8:44 PM, Adam Ruppe wrote:
Function local imports make it easier to reason about the code
which is of slight importance. The big thing I'd like though is
using it with mixins.
In my cgi.d, there's a mixin main that depends on std.string being
available inside the mixed in function.
C
"Andrei Alexandrescu" wrote in message
news:isuivh$1a6v$1...@digitalmars.com...
> On 6/10/11 8:08 PM, Michel Fortin wrote:
>> On 2011-06-10 18:57:20 -0400, Andrei Alexandrescu
>> said:
>>
>>> On 6/10/11 5:25 PM, Michel Fortin wrote:
A hack is something that works even though it's ugly and g
"Adam Ruppe" wrote in message
news:isuhab$17hb$1...@digitalmars.com...
> Function local imports make it easier to reason about the code
> which is of slight importance. The big thing I'd like though is
> using it with mixins.
>
> In my cgi.d, there's a mixin main that depends on std.string being
We should rename Yes and No to Yay and Nay to make them alignable, and
even more importantly to make us appear as old Englishmen!
Kidding. I do welcome the proposal with the prefixed Yes/No template
though, it has my vote.
"Andrei Alexandrescu" wrote in message
news:isualt$hf2$1...@digitalmars.com...
>
> Combining existing features towards new ends is in some ways more
> difficult than language design because you play within a confined ground,
> and I am a bit disappointed that a few posters have shown only conte
On Fri, 10 Jun 2011 18:16:14 -0500, Andrei Alexandrescu wrote:
> On 6/10/11 6:03 PM, Dmitry Olshansky wrote:
>> On 11.06.2011 0:58, Andrei Alexandrescu wrote:
>>> On 6/10/11 3:30 PM, Nick Sabalausky wrote:
I really see Flag more as a way to try to rationalize avoiding adding
named
p
Andrej Mitrovic:
> I've found someone that contradicts you:
> http://www.digitalmars.com/d/archives/digitalmars/D/Function-local_imports_109317.html
Thank you. That person didn't have enough experience yet, it seems. More
experienced Python programmers use local imports only in very uncommon
si
Am 11.06.2011 01:16, schrieb Andrei Alexandrescu:
Ask, and ye shall receive.
https://github.com/andralex/phobos/commit/801ccc96ce56827cd0d0b608895269bdccba4330
I like this version much more but shouldn't it also be
flag.KeepTerminator for consistency?
Mafi
bearophile wrote:
> Andrei:
>
>> This module won't compile in today's D, but not for a matter of
>> principles; it's just a random limitation of the language. (It does work
>> if you import from within a class or struct.) You can insert most
>> declarations in a scope, so the ones you can't inser
On 2011-06-10 22:08:31 -0400, Andrei Alexandrescu
said:
On 6/10/11 8:08 PM, Michel Fortin wrote:
On 2011-06-10 18:57:20 -0400, Andrei Alexandrescu
said:
https://github.com/andralex/phobos/commit/84c75336a4ef04b4c3b1924d7ac9329e744ab8e7
It's
still
a hack, but I'll agree it makes the
"Michel Fortin" wrote in message
news:isvhkr$3s4$1...@digitalmars.com...
>
> I actually didn't meant to post the above. I wrote it, then thought I
> should sleep on it before deciding whether I'd post it or not since I was
> a little to tired. Then I hit a bad key combo and the message reached
On 2011-06-11 07:01:13 -0400, "Nick Sabalausky" said:
"Michel Fortin" wrote in message
news:isvhkr$3s4$1...@digitalmars.com...
I actually didn't meant to post the above. I wrote it, then thought I
should sleep on it before deciding whether I'd post it or not since I was
a little to tired. Th
Am 11.06.2011 13:09, schrieb Michel Fortin:
> On 2011-06-11 07:01:13 -0400, "Nick Sabalausky" said:
>
>> "Michel Fortin" wrote in message
>> news:isvhkr$3s4$1...@digitalmars.com...
>>>
>>> I actually didn't meant to post the above. I wrote it, then thought I
>>> should sleep on it before decidin
On 6/10/11 11:55 PM, Nick Sabalausky wrote:
However, I still think it's a deterioration from the user's point of
view compared to the current situation with hand-crafted enums: it still
requires a string, and the documentation will say func(Flag!"abc" abc),
repeating the parameter's name unless y
1 - 100 of 228 matches
Mail list logo
