Am Sat, 24 Mar 2018 17:24:28 -0400 schrieb Andrei Alexandrescu:

> On 3/24/18 12:59 PM, H. S. Teoh wrote:
>> On Sat, Mar 24, 2018 at 12:11:18PM -0400, Andrei Alexandrescu via
>> Digitalmars-d wrote:
>> [...]
>>> Anyhow. Right now the order of processing is the same as the lexical order in which flags are passed to getopt. There may be use cases for which that's the more desirable way to go about things, so if you author a PR to change the order you'd need to build an argument on why command-line order is better. FWIW the traditional POSIX doctrine makes behavior of flags independent of their order, which would imply the current choice is more natural.
>> 
>> So what about making this configurable?
> 
> That'd be great. I'm thinking something like an option std.getopt.config.commandLineOrder. Must be first option specified right after arguments. Sounds good?

I don't really understand why you want to this keep lexical order functionality. There's a well defined use case for command line order: Allowing users to write commands in a natural, left-to-right style, where options on the right are more specific: systemctl status -l ...

I've never heard of any use case where the lexical order of the arguments passed to getopt matters for parsing user supplied command arguments. Is there any use case for this?

I thought the only reason we have this lexical order parsing is because it's simpler to implement. But if we'll get the non-quadratic command-line order implementation there's no reason to keep and maintain the quadratic implementation.

-- 
Johannes

On 3/25/18 10:22 AM, Johannes Pfau wrote:
> I don't really understand why you want to this keep lexical order
> functionality.

I don't want. I think others will, once their programs depending on the current semantics will have trouble.

On Saturday, 24 March 2018 at 21:24:28 UTC, Andrei Alexandrescu wrote:
>
> That'd be great. I'm thinking something like an option std.getopt.config.commandLineOrder. Must be first option specified right after arguments. Sounds good?

I thought this was a clever joke, but everyone is taking it seriously ?!

"When running mygreatprog.exe, always run with --command-line-order CommandLine as the first command line option, otherwise mygreatprog.exe may misinterpret the command line"

On Sunday, 25 March 2018 at 14:46:23 UTC, Abdulhaq wrote:
> On Saturday, 24 March 2018 at 21:24:28 UTC, Andrei Alexandrescu wrote:
>>
>> That'd be great. I'm thinking something like an option std.getopt.config.commandLineOrder. Must be first option specified right after arguments. Sounds good?
>
> I thought this was a clever joke, but everyone is taking it seriously ?!
>
> "When running mygreatprog.exe, always run with --command-line-order CommandLine as the first command line option, otherwise mygreatprog.exe may misinterpret the command line"

Oops sorry to reply to myself, I realise my mistake now :-)

On 3/25/18 10:48 AM, Abdulhaq wrote:
> On Sunday, 25 March 2018 at 14:46:23 UTC, Abdulhaq wrote:
>> On Saturday, 24 March 2018 at 21:24:28 UTC, Andrei Alexandrescu wrote:
>>>
>>> That'd be great. I'm thinking something like an option std.getopt.config.commandLineOrder. Must be first option specified right after arguments. Sounds good?
>>
>> I thought this was a clever joke, but everyone is taking it seriously ?!
>>
>> "When running mygreatprog.exe, always run with --command-line-order CommandLine as the first command line option, otherwise mygreatprog.exe may misinterpret the command line"
> 
> Oops sorry to reply to myself, I realise my mistake now :-)

To purge thy mistake: implement :o).

On Sunday, 25 March 2018 at 13:23:04 UTC, Rubn wrote:
> On Sunday, 25 March 2018 at 09:27:31 UTC, Walter Bright wrote:
>> On 3/23/2018 10:55 PM, Chris Katko wrote:
>>> Last question though, is there any kind of list of features, and minor features and fixes that can or need to be done? Perhaps it already exists,
>> And here it is:
>>
>> https://issues.dlang.org/
>
> Not a very comprehensive list. Virtually all of those issues have no comment on them. If it's a feature request you might as assume it requires a DIP cause there's no reason to otherwise waste your time implementing the feature.

Well, first off - most of these issues are bug reports and would obviously be pulled if fixed.
Also, bigger improvements to Phobos don't require a DIP - just Andrei's approval.
There have been many discussions on this (a recent one: https://forum.dlang.org/post/mailman.1298.1521583794.3374.digitalmars-d@puremagic.com), but in short it's going to stay like this, but you can easily shoot Andrei a mail _before_ doing something bigger at Phobos.

Now regarding language features, the DIP process has been revamped:

https://forum.dlang.org/post/p95hjs$1nf$1@digitalmars.com

> Oddly enough there's almost no other way to get anyone's attention of whether a feature requires a DIP or not unless there's a pull request for the feature. So if you want a feature you almost have to risk wasting your time implementing it.

Improvements to the language will require a DIP. Sometimes (like e.g. for a new trait) it's possible to get direct approval by Walter/Andrei on GitHub, but the rule of thumb is that it needs a DIP.

In doubt, you can discuss a new feature on Slack, IRC or this NG here.

> It's not a very good system, but someone throws up some stats about how many issues get solved/pull requests get created per month and they conclude that it's working fine.

You aren't alone:

https://github.com/wilzbach/state-of-d-2018/blob/master/09c:%20What%2C%20if%20anything%2C%20do%20you%20dislike%20about%20D's%20issue%20process%3F

https://github.com/wilzbach/state-of-d-2018/blob/master/09d:%20What%2C%20if%20anything%2C%20has%20prevented%20you%20from%20opening%20an%20issue%3F

There are many improvements hopefully coming up to issues.dlang.org in the near future:

https://forum.dlang.org/post/tneyowfjewrlrtnqsuvd@forum.dlang.org

If you have more specific ideas on what could be done to improve issues.dlang.org, share them on #dlang_org in Slack, here or in Bugzilla.

Note:
- Switch to GH issues is a common request and while I also fought for that one (I even tested an automatic migration to GH), there are quite some downsides with GH issue tracker and at the moment the consensus is to give Mozilla's fork of Bugzilla a fair try
- "there are almost no comments" on issues isn't actionable, but a system/idea to improve this would be.

On 3/25/2018 6:23 AM, Rubn wrote:
> On Sunday, 25 March 2018 at 09:27:31 UTC, Walter Bright wrote:
>> On 3/23/2018 10:55 PM, Chris Katko wrote:
>>> Last question though, is there any kind of list of features, and minor features and fixes that can or need to be done? Perhaps it already exists,
>> And here it is:
>>
>> https://issues.dlang.org/
> 
> Virtually all of those issues have no comment on them.

Hence there's plenty of "need to be done" contributions to make!

People often make very valuable contributions to issues in the comments by:

1. producing a reduced test case (the smaller the test case, the easier it is to track down)
2. finding the cause of the bug
3. finding the pull request that introduced the bug
4. connecting to related work
5. any other information helpful in resolving it

On Sunday, 25 March 2018 at 14:25:49 UTC, Andrei Alexandrescu wrote:
> I don't want. I think others will, once their programs depending on the current semantics will have trouble.

The current semantics are not documented, so any program that relies on them is foolish anyway.

Like I said in my code, I read options and run them in separate orders since I specifically want control - I imagine most everyone else does too, since otherwise you are depending on underspecified behavior and liable to break without notice.

On Sunday, 25 March 2018 at 06:58:50 UTC, Seb wrote:
> Yeah I have "dumb XYZ, roll my own" experience often too.
> As there are already many big libraries like `arsd` or `ae` out there, I don't think I'm the only one with these feeling.

In my case, there's very little overlap with what Phobos offers. And in cases where there are, it is usually either 1) built on top of phobos (e.g. my jsvar actually depends on std.json), and/or 2) older than the Phobos offering, often significantly so.

Well, there's also a few explicitly redone functions like `to` hidden inside my color.d, but that's a dependency bloat thing and less relevant now that phobos is getting its own messy import web under control (this came when importing the most trivial phobos module would triple the build time and double the executable size of all my gui apps, so the gui module tree in my libs were all phobos free, and that did mean a few trivial reimplementations but to!string(int) is like a five liner sooo easy trade there. But now the situation is much better.)


But anyway, what Phobos does, it tends to do reasonably well in my view (with a couple glaring exceptions). I kinda like std.getopt. It isn't perfect and I could do better... but it is there and it is good enough, so I defend it.

Phobos just doesn't even attempt most of what I need, so I also have a LOT of reusable add-on code that i call the arsd repo which is kinda part two of my personal D standard library :) .