On Monday, 3 February 2014 at 11:37:15 UTC, Vladimir Panteleev wrote:
>
> So, here? http://dlang.org/deprecate.html

That list is not complete.  I know of two that aren't on this list:
1) alias {newSymbol} {existingSymbol};
2) new(...) allocator.  delete is there, but new isn't


>
> Considering that fixing these problems are tedious and
> unrewarding tasks, it's not surprising that so few people step up
> to do it.

Agreed, but...

> Considering that this task does not require as much
> knowledge/experience as, e.g., hacking the compiler, IMHO the
> best people to get it done is those who actually need them done.

IMHO the best people to get it done are the ones who implement or change the feature.  The job isn't finished until they've done so.

Mike

On Friday, 7 February 2014 at 00:38:21 UTC, Mike wrote:
> IMHO the best people to get it done are the ones who implement or change the feature.  The job isn't finished until they've done so.
>
> Mike

Adding to this point: The people who need to look at the docs are almost by definition not qualified to write them.

"Mike"  wrote in message news:xtizbktwrvedtszcawhj@forum.dlang.org...
> That list is not complete.  I know of two that aren't on this list:
> 1) alias {newSymbol} {existingSymbol};

Not deprecated.

> 2) new(...) allocator.  delete is there, but new isn't

It has definitely been talked about, but that != officially deprecated.

> IMHO the best people to get it done are the ones who implement or change the feature.  The job isn't finished until they've done so.

I can't speak for all the other contributors, but if this was a requirement I would fix less bugs.  I have zero interest in writing documentation and interest is what drives me to generate compiler patches in my spare time.

I wrote most of the deprecated features page and by the end I wanted to blow my brains out. 

On Friday, 7 February 2014 at 03:36:32 UTC, Daniel Murphy wrote:
> "Mike"  wrote in message news:xtizbktwrvedtszcawhj@forum.dlang.org...
>> That list is not complete.  I know of two that aren't on this list:
>> 1) alias {newSymbol} {existingSymbol};
>
> Not deprecated.
>
>> 2) new(...) allocator.  delete is there, but new isn't
>
> It has definitely been talked about, but that != officially deprecated.
>

This is exactly what I'm talking about.  You claim to know what is and isn't deprecated, but others in this community have stated otherwise.  How do you know? You got the information from somewhere, where did you get it?

Perhaps these features are not "deprecated", but "discouraged".  We need to know that too.

I'm in the process of modelling a 1500 page MCU datasheet in D.  Each field in each register is modeled with an "alias" statement.  There will be several hundred of these when I'm done.  I already went down one path based on the documentation.  Then the community told me it was deprecated and I should go the other way.

So, I submitted a pull request to update the documentation, and it was merged.

I was even going to take on the task of modifying the D Runtime to use the supposedly "new" syntax, in an effort to be helpful.  Now I'm not so sure I should.

I also began building a class hierarchy based on the new(...) and destroy(), based on the documentation.  Only to find a day or so ago that new(...) is discouraged/deprecated.

> I can't speak for all the other contributors, but if this was a requirement I would fix less bugs.  I have zero interest in writing documentation and interest is what drives me to generate compiler patches in my spare time.

> I wrote most of the deprecated features page and by the end I wanted to blow my brains out.

I don't really like updating the GDC wiki, migrating its bug reports, or submitting pull request to fix DLang.org documentation, but I did/do it because I care and I want these efforts to succeed.

Mike

"Mike"  wrote in message news:ncdrqamncpbgfltaqrqe@forum.dlang.org...
> This is exactly what I'm talking about.  You claim to know what is and isn't deprecated, but others in this community have stated otherwise.  How do you know? You got the information from somewhere, where did you get it?

Reading this newsgroup, discussion on github, and bugzilla.

> Perhaps these features are not "deprecated", but "discouraged".  We need to know that too.

Many many features have been proposed for deprecation.  Most of those discussions have gone nowhere.  Different people have different ideas about what should be discouraged.

eg foreach_reverse

> I'm in the process of modelling a 1500 page MCU datasheet in D.  Each field in each register is modeled with an "alias" statement. There will be several hundred of these when I'm done.  I already went down one path based on the documentation.  Then the community told me it was deprecated and I should go the other way.

The community was wrong, it is not deprecated.  The new syntax is generally preferred because it is easier to read etc

> So, I submitted a pull request to update the documentation, and it was merged.
>
> I was even going to take on the task of modifying the D Runtime to use the supposedly "new" syntax, in an effort to be helpful.  Now I'm not so sure I should.

Updating the documentation to reflect best practices is always useful. Changing existing code is less of a sure thing, although in this case I doubt you'd get much opposition.  If you're worried about wasting your time with a pull request that gets rejected, start with one file and see if there's any interest from those with commit access.

> I also began building a class hierarchy based on the new(...) and destroy(), based on the documentation.  Only to find a day or so ago that new(...) is discouraged/deprecated.

Unlike many of the officially deprecated features, this one is pretty easy to ignore and doesn't seem to cause any bugs.  This makes deciding what to do with it rather unimportant.

So, it has an uncertain future and questionable value, and this would probably mean a pull request using this in phobos would not be accepted. You can still do whatever you like in your own code.

> I don't really like updating the GDC wiki, migrating its bug reports, or submitting pull request to fix DLang.org documentation, but I did/do it because I care and I want these efforts to succeed.

The great thing about being a volunteer is that you can work on the things you care about, and nothing else.  The situation improves by more people caring about the documentation, not by insisting that the people who don't care work on it too.

Andrei declaring we should spend effort on different areas is only binding for the non-volunteers, although it does help the community know that effort in those areas is desired. 

On Friday, 7 February 2014 at 05:39:29 UTC, Daniel Murphy wrote:
> "Mike"  wrote in message
>
> The great thing about being a volunteer is that you can work on the things you care about, and nothing else.  The situation improves by more people caring about the documentation, not by insisting that the people who don't care work on it too.
>

I'm finding too many floating turds, and so I ask, not insist, that people take the time to flush when they're done.

Daniel Murphy:

> Unlike many of the officially deprecated features, this one is pretty easy to ignore and doesn't seem to cause any bugs.  This makes deciding what to do with it rather unimportant.
>
> So, it has an uncertain future and questionable value, and this would probably mean a pull request using this in phobos would not be accepted. You can still do whatever you like in your own code.

Its recent warn/deprecation request:
http://d.puremagic.com/issues/show_bug.cgi?id=12081

Bye,
bearophile

On Friday, 7 February 2014 at 01:40:38 UTC, Brian Schott wrote:
> On Friday, 7 February 2014 at 00:38:21 UTC, Mike wrote:
>> IMHO the best people to get it done are the ones who implement or change the feature.  The job isn't finished until they've done so.
>>
>> Mike
>
> Adding to this point: The people who need to look at the docs are almost by definition not qualified to write them.

That is true to an extent, but I also think that in terms of writing documentation that is helpful to beginners, it is often useful to have it written by someone who is, or recently was, a beginner themselves. Often these individuals have a fresh memory of what concepts they struggled with, and what was vague in the documents.

It is sort of like how you can "wtre a snetecne in soem langauge and a procfient readr can stlil raed it, even if you psell all the wrods wrnog", because they almost sub-conciously correct all the mistakes. The same likely holds for documentation, where the expert can read the documentation and without even thinking fill in all the blanks without realizing what the blanks are.

In this respect I think even people new to the language can make a useful contribution.

On 2/7/14, 3:10 AM, Mike wrote:
> On Friday, 7 February 2014 at 05:39:29 UTC, Daniel Murphy wrote:
>> "Mike"  wrote in message
>>
>> The great thing about being a volunteer is that you can work on the
>> things you care about, and nothing else.  The situation improves by
>> more people caring about the documentation, not by insisting that the
>> people who don't care work on it too.
>>
>
> I'm finding too many floating turds, and so I ask, not insist, that
> people take the time to flush when they're done.

Now that's a good read over coffee :o).

Andrei