On Thu, May 08, 2014 at 03:13:48PM +, Dicebot via Digitalmars-d-learn wrote:
> On Thursday, 8 May 2014 at 14:34:27 UTC, H. S. Teoh via Digitalmars-d-learn
> wrote:
> >FWIW, for very long function signatures I write it this way:
> >
> > const(T)[] myVeryLongFunction(T)(const(T)[] arr,
> >
On Thursday, 8 May 2014 at 14:34:27 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
FWIW, for very long function signatures I write it this way:
const(T)[] myVeryLongFunction(T)(const(T)[] arr,
intx,
On Thu, May 08, 2014 at 02:50:54PM +, bearophile via Digitalmars-d-learn
wrote:
> H. S. Teoh:
>
> >FWIW, for very long function signatures I write it this way:
> >
> > const(T)[] myVeryLongFunction(T)(const(T)[] arr,
> > intx,
> >
H. S. Teoh:
FWIW, for very long function signatures I write it this way:
const(T)[] myVeryLongFunction(T)(const(T)[] arr,
intx,
inty,
intz,
On Thu, 8 May 2014 07:32:52 -0700
"H. S. Teoh via Digitalmars-d-learn"
wrote:
> On Thu, May 08, 2014 at 01:59:58AM -0700, Jonathan M Davis via
> Digitalmars-d-learn wrote:
> > On Thu, 08 May 2014 07:29:08 +
> > bearophile via Digitalmars-d-learn
> > wrote:
> >
> > > Jonathan M Davis:
> > >
>
On Thu, May 08, 2014 at 01:59:58AM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:
> On Thu, 08 May 2014 07:29:08 +
> bearophile via Digitalmars-d-learn
> wrote:
>
> > Jonathan M Davis:
> >
> > > ultimately, this sort of thing pretty much always ends up being
> > > highly subjective.
On Thu, 08 May 2014 10:27:17 +
bearophile via Digitalmars-d-learn
wrote:
> Jonathan M Davis:
>
> > I still think that allowing const on the left is simply a
> > bad design decision.
>
> I opened a request on this, and it was closed down :-)
I know. Walter doesn't agree that it was a bad deci
Jonathan M Davis:
I still think that allowing const on the left is simply a
bad design decision.
I opened a request on this, and it was closed down :-)
Bye,
bearophile
On Thu, 08 May 2014 09:30:38 +
bearophile via Digitalmars-d-learn
wrote:
> Jonathan M Davis:
>
> > Unfortunately, making this consistent by doing something like
> > enforcing that
> > all function attributes go on the right would then be
> > inconsistent with other
> > languages with regards
Jonathan M Davis:
Unfortunately, making this consistent by doing something like
enforcing that
all function attributes go on the right would then be
inconsistent with other
languages with regards to the attributes that they have which
go on the left,
This is a job for a Lint. like DScanner :
On Thu, 08 May 2014 07:29:08 +
bearophile via Digitalmars-d-learn
wrote:
> Jonathan M Davis:
>
> > ultimately, this sort of
> > thing pretty much always ends up being highly subjective.
>
> But please put the const/immutable of methods on the right:
>
> struct Foo {
> void bar1() const {
Jonathan M Davis:
ultimately, this sort of
thing pretty much always ends up being highly subjective.
But please put the const/immutable of methods on the right:
struct Foo {
void bar1() const {} // Good
const void bar2() {} // Bad
}
Bye,
bearophile
On Wed, 07 May 2014 18:51:58 +
Meta via Digitalmars-d-learn wrote:
> On Wednesday, 7 May 2014 at 14:40:37 UTC, Jonathan M Davis via
> Digitalmars-d-learn wrote:
> > My eyes... Oh, how that hurts readibily.
>
> While I agree that
>
> pure @safe @nogc nothrow
> void doSomething(int n)
> {
> }
>
On Wednesday, 7 May 2014 at 18:51:59 UTC, Meta wrote:
On Wednesday, 7 May 2014 at 14:40:37 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
My eyes... Oh, how that hurts readibily.
While I agree that
pure @safe @nogc nothrow
void doSomething(int n)
{
}
is quite ugly, it is really not muc
On Wednesday, 7 May 2014 at 14:40:37 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
My eyes... Oh, how that hurts readibily.
While I agree that
pure @safe @nogc nothrow
void doSomething(int n)
{
}
is quite ugly, it is really not much worse than
void doSomething(int n) pure @safe @nogc
Nick Sabalausky:
72-73 chars would indeed be a pain. In my own code I like to
use a soft limit of 80, FWIW.
This is not regular code, it's an online wiki. The situation is a
little different. But I think 80 is now acceptable.
Bye,
bearophile
On 05/07/2014 06:25 AM, bearophile wrote:
> limit to about 80 chars.
I've never worked at a place where the limit was not 80. So, from my
point of view it is still the industry standard and I like it. :)
Ali
On 5/7/2014 9:25 AM, bearophile wrote:
So far in Rosettacode D entries I've kept a line length limit of 72 or
73 chars.
But now a little larger monitors are common, D UFCS chains are common,
and we also have longer function signatures with "pure nothrow @safe
@nogc" (that usually I put on a new
On Wed, May 07, 2014 at 01:25:52PM +, bearophile via Digitalmars-d-learn
wrote:
> So far in Rosettacode D entries I've kept a line length limit of 72 or
> 73 chars.
>
> But now a little larger monitors are common, D UFCS chains are common,
> and we also have longer function signatures with "p
On Wed, 07 May 2014 13:39:55 +
Meta via Digitalmars-d-learn wrote:
> Maybe D programmers need to adopt a new convention for
> annotations in the long term. Instead of:
>
> void doSomething(int n) pure @safe @nogc nothrow
> {
> }
>
> We should write:
>
> pure @safe @nogc nothrow
> void doSometh
On Wednesday, 7 May 2014 at 13:25:55 UTC, bearophile wrote:
So far in Rosettacode D entries I've kept a line length limit
of 72 or 73 chars.
But now a little larger monitors are common, D UFCS chains are
common, and we also have longer function signatures with "pure
nothrow @safe @nogc" (that
So far in Rosettacode D entries I've kept a line length limit of
72 or 73 chars.
But now a little larger monitors are common, D UFCS chains are
common, and we also have longer function signatures with "pure
nothrow @safe @nogc" (that usually I put on a new line), so
keeping that line length l
22 matches
Mail list logo
