On 9/25/2014 9:04 PM, H. S. Teoh via Digitalmars-d wrote:
> On Thu, Sep 25, 2014 at 08:11:02PM -0700, Walter Bright via Digitalmars-d wrote:
>> Consider this PR:
>>
>> https://github.com/D-Programming-Language/phobos/pull/2423
>>
>> which is blocked because several people do not agree with using
>> byCodeunit.
>
> Actually, several committers have already agreed that this particular PR
> shouldn't be blocked pending the decision whether to autodecode or not.
> What's actually blocking it right now, is that it calls stripExtension,
> which only works with arrays, not general ranges.  (Speaking of which,
> thanks for reminding me that I need to work on that.  :-P)


It's blocked because of the autodecode issue. Don't want to need a THIRD setExtension algorithm because this one isn't done correctly.

On 9/25/14, 9:05 PM, Vladimir Panteleev wrote:
> On Thursday, 25 September 2014 at 21:49:43 UTC, H. S. Teoh via
> Digitalmars-d wrote:
>> It's not just about performance.
>
> Something I recently realized: because of auto-decoding,
> std.algorithm.find("foo", 'o') cannot be implemented using memchr.

Why not? -- Andrei

On Friday, 26 September 2014 at 05:02:08 UTC, Andrei Alexandrescu wrote:
> On 9/25/14, 9:05 PM, Vladimir Panteleev wrote:
>> On Thursday, 25 September 2014 at 21:49:43 UTC, H. S. Teoh via
>> Digitalmars-d wrote:
>>> It's not just about performance.
>>
>> Something I recently realized: because of auto-decoding,
>> std.algorithm.find("foo", 'o') cannot be implemented using memchr.
>
> Why not? -- Andrei

Sorry, got mixed up. countUntil can't, find can (but because one's counting code points, they can't be implemented on top of each other, even for arrays).

On 25/09/14 13:08, Don wrote:

> C-style declarations. Builtin sort and reverse. NCEG operators. Built-in
> complex types. float.min. @property.

Let me add: base class protection. It's deprecated but not completely removed. I have never seen base class protection being used in practice.

-- 
/Jacob Carlborg

On Thursday, 25 September 2014 at 17:45:56 UTC, Andrei Alexandrescu wrote:
> On 9/25/14, 10:26 AM, Atila Neves wrote:
>> On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg wrote:
>>> On 25/09/14 09:38, Atila Neves wrote:
>>>
>>>> Here's one: having to manually generate the custom main file for
>>>> unittest builds. There's no current way (or at least there wasn't when I
>>>> brought it up in the dub forum) to tell it to autogenerate a D file from
>>>> a dub package and list it as a dependency of the unittest build.
>>>
>>> Hmm, I haven't used Dub to run unit tests. Although, DMD has a "-main"
>>> flag that adds an empty main function.
>>
>> I don't want an empty main function. I want the main function and the
>> file it's in to be generated by the build system.
>
> Why would be the focus on the mechanism instead of the needed outcome? -- Andrei

Because I don't use unittest blocks, I use my own library. The one thing it can't use the compiler for is discover what files are in a directory, so I need to generate the main function that calls into unit-threaded with a list of compile-time strings. What I need/want is that every time I add a new source file to the project, it gets auto-generated automatically and is a dependency of the unittest build in dub.

Atila

On 9/25/2014 9:38 PM, Daniel Murphy wrote:
> "Walter Bright"  wrote in message news:m02qcm$2mmn$1@digitalmars.com...
>> What would the 3rd version of setExtension be named, then?
>
> setExtension.  Making up new clever names for functions that do the same thing
> with different types is a burden for the users.

The behavior would be different, although the types are the same.

Am Wed, 24 Sep 2014 23:56:24 +0000
schrieb "Cliff" <cliff.s.hudson@gmail.com>:

> On Wednesday, 24 September 2014 at 23:20:00 UTC, H. S. Teoh via Digitalmars-d wrote:
> > On Wed, Sep 24, 2014 at 11:02:51PM +0000, Cliff via Digitalmars-d wrote:
> >> On Wednesday, 24 September 2014 at 22:49:08 UTC, H. S. Teoh via Digitalmars-d wrote:
> >> >On Wed, Sep 24, 2014 at 10:18:29PM +0000, Atila Neves via
> >> >Digitalmars-d
> >> >wrote:
> >> >[...]
> >> >>If I were to write a build system today that had to spell
> >> >>out all of
> >> >>its commands, I'd go with tup or Ninja. That CMake has
> >> >>support for
> >> >>Ninja is the icing on the cake for me. I wrote a Ninja build
> >> >>system
> >> >>generator the other day, that thing is awesome.
> >> >[...]
> >> >>P.S. I've thought of writing a build system in D, for which
> >> >>the
> >> >>configuration language would be D. I still might. Right now,
> >> >>dub is
> >> >>serving my needs.
> >> >
> >> >I've been thinking of that too! I have in mind a hybrid
> >> >between tup
> >> >and SCons, integrating the best ideas of both and discarding
> >> >the bad
> >> >parts.
> > [...]
> >> If you have a passion and interest in this space and would
> >> like to
> >> collaborate, I would be thrilled.  We can also split this
> >> discussion
> >> off of this thread since it is not D specific.
> >
> > I'm interested. What about Atila?
> >
> >
> > T
> 
> Yes, whoever has a passionate interest in this space and (of course) an interest in D.  Probably the best thing to do is take this to another forum - I don't want to further pollute this thread.  Please g-mail to: cliff s hudson.  (I'm assuming you are a human and can figure out the appropriate dotted address from the preceding :) )

You do know that your email is in plain text in the news message header? :p

-- 
Marco

"H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote in message news:mailman.1690.1411686833.5783.digitalmars-d@puremagic.com...
> On Thu, Sep 25, 2014 at 10:56:55PM +0000, Sean Kelly via Digitalmars-d wrote:
..
>
> Nah, they should be behead() and amputate().
>
>

Then the language would have to be called jihaDi... 

On 9/25/2014 9:26 PM, Daniel Murphy wrote:
> Oh yeah.  D's one variable-sized type.

Pointers too!

On Thursday, 25 September 2014 at 13:56:20 UTC, Andrei Alexandrescu wrote:
> On 9/25/14, 4:30 AM, Joakim wrote:
>> I'm sorry but it's ridiculous for you two co-BDFLs not to put
>> these new priorities or pre-approved features (perhaps even a
>> list of features you'd automatically reject) in a list on the
>> wiki and maintain it yourselves.  It's the least you can do
>> considering the veto power you have.
>
> That's sensible. We have the "preapproved" tag at http://issues.dlang.org exactly for that kind of stuff. (I should note, however, that sometimes it backfires - I've added https://issues.dlang.org/show_bug.cgi?id=13517 with preapproved knowing it's sensible and entirely noncontroversial and got unexpected pushback for it.)

That's not enough.  While it's nice that a "preapproved" tag is being used on bugzilla, most of those issues are too low-level and an obscure bugzilla tag hardly fits the bill, particularly when most D users have never seen the D bugzilla let alone use it.  It needs to be a page on the wiki or the main site, which you or any user can link to anytime people want to know the plan.

I gave a specific example with dfix, yet to get an answer on that.  Brian may have marked his DIP 65 as rejected a couple months back, but that still doesn't answer the broader question of using a dfix tool for other cleanup.

You have talked about making D development more professional.  It's not very professional not to have some sort of public plan of where you want the language to go.  All I'm asking for is a public list of preapproved and maybe rejected features that the two of you maintain.  Dfix might be on the preapproved list, ARC might be on the rejected. ;) You could also outline broad priorities like C++ support or GC improvement on such a webpage.