On Wednesday, 24 September 2014 at 03:59:10 UTC, Walter Bright wrote:
> This is completely unworkable.

Mister, please stop hurting the pool straw man.

Let me quote the relevant part:

>>> They don't necessarily need to be blocking, just a notice "hey, your PR broke this and that project" would surely be helpful to detect the breakages early on.

I think that aside from the technical limitations, that's completely reasonable, and does not put any undue obligation on anyone.

On Wednesday, 24 September 2014 at 04:00:06 UTC, Walter Bright wrote:
> On 9/22/2014 10:16 AM, luminousone wrote:
>> What is needed?
>
> The people who maintain large projects need to try them out with the beta compilers and file any regressions.

Question: What's the point of testing betas if the release will occur even with known regressions? Blocking a pull being merged would be much more efficient than dealing with a pull merged long ago that by release time is difficult to revert.

On 9/23/2014 9:12 PM, Vladimir Panteleev wrote:
> On Wednesday, 24 September 2014 at 04:00:06 UTC, Walter Bright wrote:
>> On 9/22/2014 10:16 AM, luminousone wrote:
>>> What is needed?
>>
>> The people who maintain large projects need to try them out with the beta
>> compilers and file any regressions.
>
> Question: What's the point of testing betas if the release will occur even with
> known regressions?

Framing the question that way implies that all regressions are equally deleterious. But this isn't true at all - some regressions are disastrous, some are just minor nits. Delaying the release has its costs, too, as it may fix a number of serious problems.

It's a balancing act.

We shouldn't hamstring our ability to do what is best by conforming to arbitrary rules whether they are right or wrong for the circumstances.

> Blocking a pull being merged would be much more efficient
> than dealing with a pull merged long ago that by release time is difficult to
> revert.

Sure. I would block pulls that produce known regressions. The earlier regressions are known the better. But it is a bit unreasonable to expect large project maintainers to rebuild and check for bugs every day. It's why we have a beta test program.

On 9/23/2014 9:08 PM, Vladimir Panteleev wrote:
> On Wednesday, 24 September 2014 at 03:59:10 UTC, Walter Bright wrote:
>> This is completely unworkable.
>
> Mister, please stop hurting the pool straw man.
>
> Let me quote the relevant part:
>
>>>> They don't necessarily need to be blocking, just a notice "hey, your PR
>>>> broke this and that project" would surely be helpful to detect the breakages
>>>> early on.
>
> I think that aside from the technical limitations, that's completely reasonable,
> and does not put any undue obligation on anyone.

Who is going to maintain the autotester version of these projects?

What I'd like to see is the autotester regularly build release packages out of HEAD. Then, large project maintainers can create their own scripts to download the latest compiler and attempt to build their project.

On Wednesday, 24 September 2014 at 03:44:52 UTC, Walter Bright wrote:
> On 9/23/2014 7:29 AM, Sean Kelly wrote:
>> The lack of clear direction or communication thereof.  A continual adding of new
>> stuff to try and appease the theoretical masses who will certainly come flocking
>> to D if implemented, and a lack of attention paid to tightening up what we've
>> already got and deprecating old stuff that no one wants any more.
>
> I find this hard to reconcile with what the changelog says.

There's clearly been a lot of attention paid to bug fixes.  But for the rest... I feel like the overall direction is towards whatever is currently thought to gain the most new users.  The thing is that D has already *got* me.  What I want is for the language I've already got to be polished until I can use it in a freaking space telescope.  I'm sick of "yes but" languages.  Every time I hit an obstacle in D I think "oh great, D is way behind other languages in all these ways and D itself is broken to boot.  Why am I using this again?"  And it could be a tiny thing.  It doesn't matter.  Every little issue like that is magnified a thousandfold because D is already such a hard sell.

So in that respect I understand the push for C++ support because that's the speed bump that Andrei has hit.  But here's the thing... by pursuing this we're effectively focusing all of our efforts *on another language*.  And we're doing so when D itself still needs a lot of work.  Maybe not in any truly immense ways, but as I said before, those tiny things can seem huge when you're already struggling to justify just using the language at all.  Maybe all this will pull together into a cohesive whole, but so far it feels kind of disconnected.  So that's part of what I meant by "tightening up."


>> And inconsistency in how things work in the language.  Oh, and function attributes.
>> I'm sure someone likes them, but I'm drowning in pure system const immutable
>> @nogc @illegitemate @wtf hell.
>
> Fortunately, those attributes are inferred for template functions.
>
> I did try to extend that to auto functions, but got a lot of resistance.

Yes, the inference is very nice.  And I do see the use for each attribute.  It's just... when I look at a function and there's a line of attributes before the function declaration that have nothing to do with what the function actually does but rather with how it's implemented, it's just syntactic noise.  It's information for the compiler, not me as a user.  I hope we'll eventually get to the point where everything is inferred and the attributes disappear entirely.

On 9/23/2014 9:46 PM, Sean Kelly via Digitalmars-d wrote:
> There's clearly been a lot of attention paid to bug fixes.  But for the
> rest... I feel like the overall direction is towards whatever is
> currently thought to gain the most new users.  The thing is that D has
> already *got* me.  What I want is for the language I've already got to
> be polished until I can use it in a freaking space telescope.  I'm sick
> of "yes but" languages. Every time I hit an obstacle in D I think "oh
> great, D is way behind other languages in all these ways and D itself is
> broken to boot.  Why am I using this again?"  And it could be a tiny
> thing.  It doesn't matter.  Every little issue like that is magnified a
> thousandfold because D is already such a hard sell.

I agree with Sean quite a bit here.

Let's turn the camera around and look at it from a different angle.  I'm hard pressed to find a new feature from the last few years that's actually thoroughly complete.  And by complete I mean that druntime and phobos use it everywhere it should be used.

Shared libraries?  nope.
Any of the new attributes?  nope.
64 bit support?  nope.
const?
shared?
cleaning up object?

.. nope.

And that's not even getting into the big gaps that exist.

I understand quite thoroughly why c++ support is a big win, or will be, but the Oh Shiny focus is pretty discouraging for me as well.  This isn't meant to say the c++ work shouldn't be done, but to point out that the shifting focus is a real problem.

On Wed, Sep 24, 2014 at 04:46:00AM +0000, Sean Kelly via Digitalmars-d wrote:
> On Wednesday, 24 September 2014 at 03:44:52 UTC, Walter Bright wrote:
> >On 9/23/2014 7:29 AM, Sean Kelly wrote:
[...]
> There's clearly been a lot of attention paid to bug fixes.  But for the rest... I feel like the overall direction is towards whatever is currently thought to gain the most new users.  The thing is that D has already *got* me.  What I want is for the language I've already got to be polished until I can use it in a freaking space telescope.  I'm sick of "yes but" languages.  Every time I hit an obstacle in D I think "oh great, D is way behind other languages in all these ways and D itself is broken to boot.  Why am I using this again?"  And it could be a tiny thing.  It doesn't matter.  Every little issue like that is magnified a thousandfold because D is already such a hard sell.

Yeah, I wish that at least *some* attention would be paid to refining existing features so that problematic corner cases could be ironed out. Like identifier lookup rules for local imports. And what to do about dtors. And so many little niggling details that seem minor, but added together, can form a pretty big mountain of frustration sometimes.


[...]
> >>And inconsistency in how things work in the language.  Oh, and function attributes.  I'm sure someone likes them, but I'm drowning in pure system const immutable @nogc @illegitemate @wtf hell.
> >
> >Fortunately, those attributes are inferred for template functions.
> >
> >I did try to extend that to auto functions, but got a lot of resistance.

I support attribute inference for auto functions. The more inference, the better, I say. That's the only way attributes will become practically useful.


> Yes, the inference is very nice.  And I do see the use for each attribute.  It's just... when I look at a function and there's a line of attributes before the function declaration that have nothing to do with what the function actually does but rather with how it's implemented, it's just syntactic noise.  It's information for the compiler, not me as a user.  I hope we'll eventually get to the point where everything is inferred and the attributes disappear entirely.

I haven't actually tried this yet, but I'm been toying with the idea of writing *all* functions as template functions (except where impossible, like virtual functions), even if they would take only zero compile-time arguments. This way, I reap the benefits of attribute inference, *and* I also get automatic culling of unused functions from the executable ('cos they wouldn't be instantiated in the first place).


T

-- 
Just because you survived after you did it, doesn't mean it wasn't stupid!

On 9/23/2014 10:10 PM, H. S. Teoh via Digitalmars-d wrote:
> Yeah, I wish that at least *some* attention would be paid to refining
> existing features so that problematic corner cases could be ironed out.

It's kinda maddening to hear statements like that. Just in 2.066:

103 compiler regressions fixed
235 compiler bugs fixed
39 language enhancements
12 phobos regressions fixed
110 phobos bugs fixed
41 phobos enhancements
9 druntime regressions fixed
17 druntime bugs fixed
9 druntime enhancements

https://dlang.org/changelog.html#list2066


> Like identifier lookup rules for local imports.

Suddenly this issue goes to a mountain overnight. Is it really the most critical, important problem, overshadowing everything else?


> And what to do about
> dtors. And so many little niggling details that seem minor, but added
> together, can form a pretty big mountain of frustration sometimes.

So help out!


> I haven't actually tried this yet, but I'm been toying with the idea of
> writing *all* functions as template functions (except where impossible,
> like virtual functions), even if they would take only zero compile-time
> arguments. This way, I reap the benefits of attribute inference, *and* I
> also get automatic culling of unused functions from the executable ('cos
> they wouldn't be instantiated in the first place).

Yup, give it a try.

On Tue, 23 Sep 2014 21:59:53 -0700
Brad Roberts via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> I understand quite thoroughly why c++ support is a big win
i believe it's not.

so-called "enterprise" will not choose D for many reasons, and "c++ interop" is on the bottom of the list.

seasoned c++ developer will not migrate to D for many reasons (or he already did that, but then he is not c++ developer anymore), and "c++ interop" is not on the top of the list, not even near the top.

all that gory efforts aimed to "c++ interop" will bring three and a half more users. there will be NO massive migration due to "better c++ interop". yet this feature is on the top of the list now. i'm sad.

seems that i (we?) have no choice except to wait until people will get enough of c++ games and will became focused on D again. porting and merging CDGC is much better target which help people already using D, but... but imaginary "future adopters" seems to be the highest priority. too bad that they will never arrive.

On 9/23/14, 9:46 PM, Sean Kelly wrote:
> So in that respect I understand the push for C++ support because that's
> the speed bump that Andrei has hit.  But here's the thing... by pursuing
> this we're effectively focusing all of our efforts *on another
> language*.  And we're doing so when D itself still needs a lot of work.
> Maybe not in any truly immense ways, but as I said before, those tiny
> things can seem huge when you're already struggling to justify just
> using the language at all. Maybe all this will pull together into a
> cohesive whole, but so far it feels kind of disconnected.  So that's
> part of what I meant by "tightening up."

You need a spoon of rennet to turn a bucket of milk into a bucket of yogurt. No matter how much milk you add, that won't help. You want to add milk. I know we must add rennet. -- Andrei