On Tue, 17 Mar 2015 10:36:47 +0100, Jacob Carlborg wrote:

> On 2015-03-16 01:13, Rikki Cattermole wrote:
> 
>> Its just a real pain to create these stubs by hand. Atleast this way, people will moan about documentation being empty and it'll seem less work to do.
> 
> This should be done by the editor.

and code formatting too...

On 03/15/2015 12:15 AM, Brian Schott wrote:
> What am I missing?

Sorry haven't read the whole thread.
I think there should be an option (even default on) to allow small
single line functions.

This can sometimes be fairly annoying. For example when writing range
adapters, see
https://github.com/D-Programming-Language/phobos/blob/77152b537b4cc6482d6181c17866475f1115beb9/std/range/package.d#L216.

bool empty() { return arr.length == 0; }
T opIndex(size_t i) { return arr[idx]; }
T front() { return arr[0]; }
void popFront() { arr = arr[1 .. $]; }

This currently expands to 20 lines of code.

bool empty()
{
    return arr.length == 0;
}

T opIndex(size_t i)
{
    return arr[idx];
}

T front()
{
    return arr[0];
}

void popFront()
{
    arr = arr[1 .. $];
}

On 3/22/15 10:05 AM, Martin Nowak wrote:
> On 03/15/2015 12:15 AM, Brian Schott wrote:
>> What am I missing?
>
> Sorry haven't read the whole thread.
> I think there should be an option (even default on) to allow small
> single line functions.
>
> This can sometimes be fairly annoying. For example when writing range
> adapters, see
> https://github.com/D-Programming-Language/phobos/blob/77152b537b4cc6482d6181c17866475f1115beb9/std/range/package.d#L216.
>
> bool empty() { return arr.length == 0; }
> T opIndex(size_t i) { return arr[idx]; }
> T front() { return arr[0]; }
> void popFront() { arr = arr[1 .. $]; }

Agreed. Also, a thought: a mixin sounds like a nice way to generate such boilerplate if frequent. -- Andrei

On 2015-03-22 18:05, Martin Nowak wrote:

> Sorry haven't read the whole thread.
> I think there should be an option (even default on) to allow small
> single line functions.
>
> This can sometimes be fairly annoying. For example when writing range
> adapters, see
> https://github.com/D-Programming-Language/phobos/blob/77152b537b4cc6482d6181c17866475f1115beb9/std/range/package.d#L216.
>
> bool empty() { return arr.length == 0; }
> T opIndex(size_t i) { return arr[idx]; }
> T front() { return arr[0]; }
> void popFront() { arr = arr[1 .. $]; }

I really don't like this way of formatting code. Although I would like that the D syntax allowed to drop the curly braces, like with if-satements. That would result in much nicer one-liner functions.

-- 
/Jacob Carlborg

Jacob Carlborg:

> Although I would like that the D syntax allowed to drop the
> curly braces, like with if-satements. That would result
> in much nicer one-liner functions.

See:
https://issues.dlang.org/show_bug.cgi?id=7176

Bye,
bearophile

On Sunday, 22 March 2015 at 17:05:27 UTC, Martin Nowak wrote:
> I think there should be an option (even default on) to allow small
> single line functions. (snip)

Perhaps it's too much to wish for, but I think the editor would be the better place for this. IntelliJ IDEA can display short methods as single line. They're still multiline in the source, but on screen they're nice. They used a similar thing with anonymous classes in Java prior to lambdas hitting the language, making single method anonymous classes look almost like the lambdas do today.

On 2015-03-23 10:47, bearophile wrote:

> See:
> https://issues.dlang.org/show_bug.cgi?id=7176

Exactly.

-- 
/Jacob Carlborg

On 03/23/2015 10:55 AM, "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= <shorttail@hotmail.com>" wrote:
> 
> Perhaps it's too much to wish for, but I think the editor would be the better place for this. IntelliJ IDEA can display short methods as single line. They're still multiline in the source, but on screen they're nice. They used a similar thing with anonymous classes in Java prior to lambdas hitting the language, making single method anonymous classes look almost like the lambdas do today.

Why would you write out code that everyone reads abbreviated?
Source code is still targeted at human readability not machine parsing.

On 2015-03-14 23:15:34 +0000, Brian Schott said:

> First, a disclaimer: I am an idiot for starting this thread.
> 
> Moving on...
> 
> I'm working on a list of configuration options for dfmt - a formatter for D source code.
> 
> So far I have the following:
> 
> * Insert spaces between if, while, for, foreach, etc loops and the "("
> * Allman vs One True Brace Style (Already supported by commant-line switch)
> * Operators at the end of the old line vs beginning of the new line when wrapping long expressions.
> * Insert space after the ")" of a cast expression
> * Make "case" and "default" match the indent level of the enclosing "switch"
> * Labels for loops always on their own line vs the same line as the loop
> * Labels outdented one level
> * Label indentation matches the most recent "switch"
> * Hard limit for line length
> * Soft limit for line length
> 
> What am I missing?

A way to configure this and have it look for the most relevant `.dfmtcfg` file! :)

That is to say, make it look up from the current directory recursively until it finds a config file, and use that.    This will greatly help people who are contributing to the same project keep a consistent format.  Also,  Hard and soft limit for line length causes an exception to be thrown when I tried it.

-Shammah

On 03/27/2015 04:30 PM, Shammah Chancellor wrote:
>> What am I missing?
> 
> A way to configure this and have it look for the most relevant `.dfmtcfg` file! :)
> 
> That is to say, make it look up from the current directory recursively until it finds a config file, and use that.    This will greatly help people who are contributing to the same project keep a consistent format.  Also,  Hard and soft limit for line length causes an exception to be thrown when I tried it.
> 
> -Shammah
> 

I proposed to use .editorconfig for this, as it already tries to standardize most of the configurations. https://github.com/Hackerpilot/dfmt/issues/122