Re: Flag proposal

On 2011-06-10 09:15, Andrei Alexandrescu wrote: > https://github.com/D-Programming-Language/phobos/pull/94 > > Discuss! Okay. Let's see if I can summarize this. Andrei thinks that have a categorized boolean type which is explicit about what it's used for is valuable. So, for instance, std.algor

Re: Flag proposal

On 6/11/11 11:20 PM, Jonathan M Davis wrote: 1. Programmers following this idiom (including the Phobos devs) end up creating enums with yes and no values and are effectively identical to other enums except for their names. So, we end up with a fair bit of boilerplate code just to pass a strict bo

Re: pragma(mangle)

"Nick Sabalausky" wrote in message news:it0m05$6t7$1...@digitalmars.com... > > It sounds like it may have great potential for working around hashed > mangles. And maybe for exposing an API to another link-compatible language > like C (or not, I don't know, maybe extern(C) is always good enough

Re: Flag proposal

On 2011-06-11 14:32, David Nadlinger wrote: > On 6/11/11 11:20 PM, Jonathan M Davis wrote: > > 1. Programmers following this idiom (including the Phobos devs) end up > > creating enums with yes and no values and are effectively identical to > > other enums except for their names. So, we end up with

Re: Flag proposal

Jonathan M Davis wrote: > ... > The complaints about this generally seem to be one of these: > > 1. Dislike of the yes/no enum idiom in the first place. Regardless of how Flag > does it, it's a problem, because it's promoting an idiom that the poster > dislikes in the first place. > > 2. Flag!"enum

Re: TempAlloc Overhaul

I don't see what's so bad about it. core.memory.GC is a struct which wraps malloc and free. If that were naked, and TempAlloc was too, then you would have erratic behavior if you missplaced one import with another by accident.

Re: pragma(mangle)

On 6/11/11, Daniel Murphy wrote: > You could use it, for example, to provide a function with C++ linkage taking > a C++ long parameter, something which I think is currently impossible in D. I assumed I must have been doing something wrong when I filed this: http://d.puremagic.com/issues/show_bug.

Re: Flag proposal

Michel Fortin: > > Took me less time than what I took arguing about Flag!"". I don't know if Walter will appreciate this, or if this will need improvements, but you have done something better than my posts where I j

Re: pragma(mangle)

"Andrej Mitrovic" wrote in message news:mailman.825.1307830585.14074.digitalmar...@puremagic.com... > On 6/11/11, Daniel Murphy wrote: >> You could use it, for example, to provide a function with C++ linkage >> taking >> a C++ long parameter, something which I think is currently impossible in

Re: article comppetition

On Sat, Jun 11, 2011 at 5:54 AM, Bernard Helyer wrote: > On Sat, 11 Jun 2011 08:48:19 -0400, alan marble wrote: > > > I wanted to believe that after all the shit D would now finally take off > > thanks to the article competition. I was A BIT surprised to see how > > small amount of articles AND v

Re: pragma(mangle)

On 11/06/2011 23:15, Andrej Mitrovic wrote: On 6/11/11, Daniel Murphy wrote: You could use it, for example, to provide a function with C++ linkage taking a C++ long parameter, something which I think is currently impossible in D. I assumed I must have been doing something wrong when I filed t

Re: TempAlloc Overhaul

dsimcha: > I've overhauled my TempAlloc proposal based on some of the suggestions I've > received. It's improved :-) >3. Make alignedMalloc and friends private for now, again to make the proposal >more tightly focused.< They are useful so I'd like such alignedCMalloc / free to be generally

Re: article comppetition

Andrew Wiley wrote: > --0016e6d27c62d1325d04a5777a93 > Content-Type: text/plain; charset=ISO-8859-1 > > On Sat, Jun 11, 2011 at 5:54 AM, Bernard Helyer wrote: > > > On Sat, 11 Jun 2011 08:48:19 -0400, alan marble wrote: > > > > > I wanted to believe that after all the shit D would now finally take

Re: pragma(mangle)

On 6/12/11, Nick Sabalausky wrote: > Are you working on updating DDMD to a newer DMD, or just simply trying to > use the newer backend? If the former, then that's fantastic and I look > forward to it. I'd like to really work on it properly (it would seem like an exciting project to work on!), and

Re: TempAlloc Overhaul

> dsimcha: > > > I've overhauled my TempAlloc proposal based on some of the suggestions I've > > received. One more thing: now TempAlloc is one single struct, so I think it's better to move it in a module that contains stuff for alternative memory managements. Creating a little Phobos module j

Re: pragma(mangle)

On 6/12/11, Robert Clipsham wrote: > On 11/06/2011 23:15, Andrej Mitrovic wrote: >> On 6/11/11, Daniel Murphy wrote: >>> You could use it, for example, to provide a function with C++ linkage >>> taking >>> a C++ long parameter, something which I think is currently impossible in >>> D. >> >> I ass

Re: pragma(mangle)

"Robert Clipsham" wrote in message news:it0rec$mii$1...@digitalmars.com... > On 11/06/2011 23:15, Andrej Mitrovic wrote: >> On 6/11/11, Daniel Murphy wrote: >>> You could use it, for example, to provide a function with C++ linkage >>> taking >>> a C++ long parameter, something which I think is

Re: TempAlloc Overhaul

On 6/11/2011 7:04 PM, bearophile wrote: dsimcha: I've overhauled my TempAlloc proposal based on some of the suggestions I've received. It's improved :-) 3. Make alignedMalloc and friends private for now, again to make the proposal more tightly focused.< They are useful so I'd like suc

Re: article comppetition

Am 12.06.2011 00:47, schrieb Andrew Wiley: > On Sat, Jun 11, 2011 at 5:54 AM, Bernard Helyer wrote: > >> On Sat, 11 Jun 2011 08:48:19 -0400, alan marble wrote: >> >>> I wanted to believe that after all the shit D would now finally take off >>> thanks to the article competition. I was A BIT surpri

delegate(in int) not convertible to delegate(int)

Is this intentional?

Re: delegate(in int) not convertible to delegate(int)

On 6/12/11 2:47 AM, Mehrdad wrote: Is this intentional? No, certainly not – please file an issue at http://d.puremagic.com/issues if not already present. David

Problem with string.whitespace and newline

The following code cannot be compiled string clean(string x) { return join(split(x),whitespace); } The compile error is Error 2 Error: template std.array.join(RoR,R) if (isInputRange!(RoR) && isInputRange!(ElementType!(RoR)) && isForwardRange!(R)) cannot deduce template function fr

Re: Problem with string.whitespace and newline

try return join(split(x),whitespace[]); It seems whitespace is a static array. On 6/12/11, Michael Chen wrote: > The following code cannot be compiled > string clean(string x) > { > return join(split(x),whitespace); > } > > The compile error is > Error 2 Error: template std.array.joi

Re: Problem with string.whitespace and newline

Thanks Andrej, it works. On Sun, Jun 12, 2011 at 9:14 AM, Andrej Mitrovic wrote: > try return join(split(x),whitespace[]); > > It seems whitespace is a static array. > > On 6/12/11, Michael Chen wrote: >> The following code cannot be compiled >> string clean(string x) >> { >>       return join(s

Re: Flag proposal [OT]

On Sat, 11 Jun 2011 13:04:47 -0400, Andrej Mitrovic wrote: On 6/11/11, Alix Pexton wrote: On 11/06/2011 06:18, Andrej Mitrovic wrote: 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! "Yay" and "Nay" are too

Re: Problem with string.whitespace and newline

I've said it before, but I'll say it again: this is such a common error that it needs a better error message. Something as simple as this will do: "foo can't take bar of type char[16]. Try using a slice: bar[]".

Re: Flag proposal

On Sat, 11 Jun 2011 17:32:56 -0400, David Nadlinger wrote: On 6/11/11 11:20 PM, Jonathan M Davis wrote: 1. Programmers following this idiom (including the Phobos devs) end up creating enums with yes and no values and are effectively identical to other enums except for their names. So, we e

Re: Problem with string.whitespace and newline

On 2011-06-11 18:46, Andrej Mitrovic wrote: > I've said it before, but I'll say it again: this is such a common > error that it needs a better error message. Something as simple as > this will do: > "foo can't take bar of type char[16]. Try using a slice: bar[]". Have you created an enhancement re

Re: Problem with string.whitespace and newline

I can't seem to find anything specific like an enhancement request. Here's a similar report by you: http://d.puremagic.com/issues/show_bug.cgi?id=4971 Maybe we should have a 'common (newbie) mistakes' section on the website and add this bit of information there.

Re: Problem with string.whitespace and newline

On 2011-06-11 19:29, Andrej Mitrovic wrote: > I can't seem to find anything specific like an enhancement request. > > Here's a similar report by you: > http://d.puremagic.com/issues/show_bug.cgi?id=4971 > > Maybe we should have a 'common (newbie) mistakes' section on the > website and add this bi

Re: Problem with string.whitespace and newline

On 2011-06-11 19:41, Jonathan M Davis wrote: > On 2011-06-11 19:29, Andrej Mitrovic wrote: > > I can't seem to find anything specific like an enhancement request. > > > > Here's a similar report by you: > > http://d.puremagic.com/issues/show_bug.cgi?id=4971 > > > > Maybe we should have a 'common

Re: Flag proposal

On 6/11/2011 12:58 PM, Andrei Alexandrescu wrote: On 6/11/11 1:59 PM, Michel Fortin wrote: On 2011-06-11 13:08:48 -0400, Andrei Alexandrescu said: With named parameters, we'd have something along the lines of: topNIndex(a, sortOutput : true); which is nice, but not present in the language (

Re: TempAlloc Overhaul

bearophile, some way in which you are replying causes Thunderbird to lose track of the thread you are replying to, and starts a new thread.

Re: Flag proposal

On 06/11/2011 04:20 PM, Jonathan M Davis wrote: 2. He proposed a template wrapper which would allow you to type yes!"enumName" and no!"enumName" instead of the full Flag!"enumName".yes and Flag!"enumName".no. Some people feel that this resolves complaint #2. Others think that it's still quite ugl

Re: Flag proposal

On 06/11/2011 03:52 PM, Nick Sabalausky wrote: "Andrei Alexandrescu" wrote in message news:it07ni$1pvj$1...@digitalmars.com... Anyway, that was the first thing "grep yes std/*" found. Let's see the next one: /** Specifies whether the output of certain algorithm is desired in sorted format.

Re: Flag proposal

On 06/11/2011 10:05 PM, Walter Bright wrote: On 6/11/2011 12:58 PM, Andrei Alexandrescu wrote: On 6/11/11 1:59 PM, Michel Fortin wrote: On 2011-06-11 13:08:48 -0400, Andrei Alexandrescu said: With named parameters, we'd have something along the lines of: topNIndex(a, sortOutput : true); wh

Re: Flag proposal

On 06/11/2011 04:58 PM, Timon Gehr wrote: Jonathan M Davis wrote: ... The complaints about this generally seem to be one of these: 1. Dislike of the yes/no enum idiom in the first place. Regardless of how Flag does it, it's a problem, because it's promoting an idiom that the poster dislikes in

Re: Flag proposal

On 06/11/2011 04:42 PM, Jonathan M Davis wrote: On 2011-06-11 14:32, David Nadlinger wrote: On 6/11/11 11:20 PM, Jonathan M Davis wrote: 1. Programmers following this idiom (including the Phobos devs) end up creating enums with yes and no values and are effectively identical to other enums exce

Re: Flag proposal

On 2011-06-11 20:27, Andrei Alexandrescu wrote: > On 06/11/2011 03:52 PM, Nick Sabalausky wrote: > > "Andrei Alexandrescu" wrote in message > > news:it07ni$1pvj$1...@digitalmars.com... > > > >> Anyway, that was the first thing "grep yes std/*" found. Let's see the > >> next one: > >> > >> /** >

Re: Flag proposal

On 2011-06-11 20:44, Andrei Alexandrescu wrote: > On 06/11/2011 04:42 PM, Jonathan M Davis wrote: > > On 2011-06-11 14:32, David Nadlinger wrote: > >> On 6/11/11 11:20 PM, Jonathan M Davis wrote: > >>> 1. Programmers following this idiom (including the Phobos devs) end up > >>> creating enums with

Re: Flag proposal

On 2011-06-11 20:50, Jonathan M Davis wrote: > On 2011-06-11 20:44, Andrei Alexandrescu wrote: > > On 06/11/2011 04:42 PM, Jonathan M Davis wrote: > > > On 2011-06-11 14:32, David Nadlinger wrote: > > >> On 6/11/11 11:20 PM, Jonathan M Davis wrote: > > >>> 1. Programmers following this idiom (inclu

Re: Removing undefined behavior of bitshifts

Am 09.06.2011 09:08, schrieb Don: s_lange wrote: As of yet, there are only general-pupose integer rotate instructions on x86 processors, and very few other CPUs and µCs actually implement rotate instructions. Really? Itanium, PowerPC, ARM, 6502, Z80, PIC all have rotate instructions. I've nev

Re: Flag proposal

On 06/11/2011 10:45 PM, Jonathan M Davis wrote: Yes, though there is a distinct difference between having to create a functor elswhere to just to call an STL function and creating an extra enum next to your function definition for one of its parameters. The parameter issue is far smaller IMHO.

Re: Flag proposal

On 6/12/11, Andrei Alexandrescu wrote: > Funny thing is, > the change is tiny. You seem to be forgetting that there are library writers and then there are library *users*. :) Seeing Flag!"foo".yes in the calling code scared people. So naturally people wanted to nuke it from orbit. If the proposa

Re: Removing undefined behavior of bitshifts

Timon Gehr Wrote: > Timon Gehr wrote: > > On 07/06/2011 00:20, Timon Gehr wrote: > > > >> I'd much prefer the behavior to be defined as 1< >> 1<<(0x1f&x); (That's what D effectively does during runtime. It is also > >> what > >> the machine code supports, at least in x87). > > > > Defining the b

Re: Flag proposal

On Jun 12, 11 11:18, Andrei Alexandrescu wrote: On 06/11/2011 04:20 PM, Jonathan M Davis wrote: 2. He proposed a template wrapper which would allow you to type yes!"enumName" and no!"enumName" instead of the full Flag!"enumName".yes and Flag!"enumName".no. Some people feel that this resolves com

core.sys/core.stdc vs. std.c?

core.stdc is the place for C standard library modules, core.sys.* are where the C operating system header translations reside – this is our current policy, right? If so (I can't actually remember any formal decision or discussion), is there a reason we still have so much code in std.c? David

Re: core.sys/core.stdc vs. std.c?

On 2011-06-11 23:38, David Nadlinger wrote: > core.stdc is the place for C standard library modules, core.sys.* are > where the C operating system header translations reside – this is our > current policy, right? If so (I can't actually remember any formal > decision or discussion), is there a reas

Re: core.sys/core.stdc vs. std.c?

Am 12.06.2011 08:38, schrieb David Nadlinger: > core.stdc is the place for C standard library modules, core.sys.* are > where the C operating system header translations reside – this is our > current policy, right? If so (I can't actually remember any formal > decision or discussion), is there a re

<    1   2