On Mon, Aug 09, 2021 at 05:37:26PM +0000, Alexandru Ermicioi via Digitalmars-d wrote:
> On Monday, 9 August 2021 at 12:14:27 UTC, Dukc wrote:
> > I can see no other reasons for disallowing free functions or requiring curly braces for every singe `if` or `while` statement.
> 
> Java is object oriented only language, hence it makes sense to not have free functions as in C++, and you actually do have free functions there. They are static methods.

I find this to be silly OO-extremism on Java's part.  Static methods of a singleton class are basically free global functions.  Why can't they just *be* global free functions?!  But nooo, that would not jive with the OO agenda, so we have to wrap that in a singleton class just to do lip service to the OO dogma and pacify the OO police.  We're eating the greasy unhealthy food of global free functions, but to pacify our OO conscience we order the diet coke of a singleton class's static methods.

Seriously, just call it what it is already.


> Braces are not required for control statements, but encouraged to avoid ambiguous then statements.
[...]

This one I actually agree with. (Even if I do find it annoying
sometimes.)

Ambiguous statements are actually worse than they appear at first glance, because of long-term maintainability issues. Consider this code where braces are omitted:

	if (someCondition)
		doSomething();
	else
		doSomethingElse();
	finishUp();

Imagine if some time later somebody discovers a bug, and introduces this fix:

	if (someCondition)
		doSomething();
	else
		doSomethingElse();
		return 1;	// <--- bugfix
	finishUp();

Had braces been required, the `return 1;` would have been introduced in the proper scope and there would have been no problem. But now this fix has introduced a new bug.


T

-- 
The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a. -- Wouter Verhelst

On Monday, 9 August 2021 at 18:00:23 UTC, H. S. Teoh wrote:
> 	if (someCondition)
> 		doSomething();
> 	else
> 		doSomethingElse();
> 		return 1;	// <--- bugfix
> 	finishUp();
>
> Had braces been required, the `return 1;` would have been introduced in the proper scope and there would have been no problem. But now this fix has introduced a new bug.
>
>
> T

The above code will fail to compile in recent C/C++ compilers, because of suspected intentional backdoors hiding in plain sight using this technique.

<source>:7:5: warning: this 'else' clause does not guard... [-Wmisleading-indentation]
<source>:9:9: note: ...this statement, but the latter is misleadingly indented as if it were

Thus there's no longer a good reason to avoid this style, unless you are using a compiler where this is not yet implemented.

On Mon, Aug 09, 2021 at 06:23:42PM +0000, Daniel N via Digitalmars-d wrote:
> On Monday, 9 August 2021 at 18:00:23 UTC, H. S. Teoh wrote:
> > 	if (someCondition)
> > 		doSomething();
> > 	else
> > 		doSomethingElse();
> > 		return 1;	// <--- bugfix
> > 	finishUp();
> > 
> > Had braces been required, the `return 1;` would have been introduced in the proper scope and there would have been no problem. But now this fix has introduced a new bug.
[...]
> The above code will fail to compile in recent C/C++ compilers, because of suspected intentional backdoors hiding in plain sight using this technique.
> 
> <source>:7:5: warning: this 'else' clause does not guard...
> [-Wmisleading-indentation]
> <source>:9:9: note: ...this statement, but the latter is misleadingly
> indented as if it were
> 
> Thus there's no longer a good reason to avoid this style, unless you are using a compiler where this is not yet implemented.

I would not trust a coding style that depends on the compiler to warn about mistakes.  What if the compiler fails to issue the warning in some obscure corner cases?  It's completely preventable: just don't write code this way.

Besides, it's kinda sad that C is moving towards Python-style indentation sensitivity...


T

-- 
This is a tpyo.

On Monday, 9 August 2021 at 18:00:23 UTC, H. S. Teoh wrote:
> [snip]
>
> Imagine if some time later somebody discovers a bug, and introduces this fix:
>
> 	if (someCondition)
> 		doSomething();
> 	else
> 		doSomethingElse();
> 		return 1;	// <--- bugfix
> 	finishUp();
>
> Had braces been required, the `return 1;` would have been introduced in the proper scope and there would have been no problem. But now this fix has introduced a new bug.
>
>
> T

I strongly prefer requiring the braces are here.

On Monday, 9 August 2021 at 17:03:57 UTC, H. S. Teoh wrote:

> Floating-point, if anything, is *more* complex and comes with more pitfalls than signed/unsigned mistakes. Worse yet, it *appears* to behave like what most people imagine real numbers to behave, but in fact doesn't, which makes mistakes more likely, and also harder to catch because they usually only crop up in special corner cases while generally appearing to work correctly.

There's an important difference though. Signed/unsigned mistakes are a choice the programming language designer makes - Walter made his choice and Gosling made a different choice. You're more or less stuck with the limitations of floating point.

On Mon, Aug 09, 2021 at 07:01:18PM +0000, bachmeier via Digitalmars-d wrote:
> On Monday, 9 August 2021 at 17:03:57 UTC, H. S. Teoh wrote:
> 
> > Floating-point, if anything, is *more* complex and comes with more pitfalls than signed/unsigned mistakes.
[...]
> There's an important difference though. Signed/unsigned mistakes are a choice the programming language designer makes - Walter made his choice and Gosling made a different choice. You're more or less stuck with the limitations of floating point.

Thing is, Java can (somewhat) get away with it because it's designed to run in an idealized VM environment, abstracted away from the ugly details of the underlying hardware.  But D is a systems programming language, so it should not hide the ugly realities of the hardware that it runs on.  By using a systems programming language you kinda signed up for this, in a sense.

As Knuth once said:

	People who are more than casually interested in computers should
	have at least some idea of what the underlying hardware is like.
	Otherwise the programs they write will be pretty weird.
	-- D. Knuth

That includes knowing the ugly realities of 2's complement arithmetic.


T

-- 
Klein bottle for rent ... inquire within. -- Stephen Mulraney

On Monday, 9 August 2021 at 19:23:14 UTC, H. S. Teoh wrote:
> As Knuth once said:
>
> 	People who are more than casually interested in computers should
> 	have at least some idea of what the underlying hardware is like.
> 	Otherwise the programs they write will be pretty weird.
> 	-- D. Knuth
>
> That includes knowing the ugly realities of 2's complement arithmetic.

The way I remember it, 2's complement notation is a method of encoding signed integers as unsigned integers such that a CPU can use the same instructions and circuits for both signed and unsigned arithmetic.

So, from the hardware's point of view, unsigned arithmetic is the pure, simple version, and signed arithmetic is the ugly, complex version. :)

On Mon, Aug 09, 2021 at 08:18:26PM +0000, Paul Backus via Digitalmars-d wrote:
> On Monday, 9 August 2021 at 19:23:14 UTC, H. S. Teoh wrote:
> > As Knuth once said:
> > 
> > 	People who are more than casually interested in computers should
> > 	have at least some idea of what the underlying hardware is like.
> > 	Otherwise the programs they write will be pretty weird.
> > 	-- D. Knuth
> > 
> > That includes knowing the ugly realities of 2's complement arithmetic.
> 
> The way I remember it, 2's complement notation is a method of encoding signed integers as unsigned integers such that a CPU can use the same instructions and circuits for both signed and unsigned arithmetic.
> 
> So, from the hardware's point of view, unsigned arithmetic is the pure, simple version, and signed arithmetic is the ugly, complex version. :)

Indeed!  If you look at the assembly level, unsigned arithmetic is the one with straightforward instructions mapping 1-to-1 with arithmetic operations, whereas signed arithmetic is the one that involves carry bits and other such additional complications.


T

-- 
Heads I win, tails you lose.

On Monday, 9 August 2021 at 21:05:05 UTC, H. S. Teoh wrote:
> Indeed!  If you look at the assembly level, unsigned arithmetic is the one with straightforward instructions mapping 1-to-1 with arithmetic operations, whereas signed arithmetic is the one that involves carry bits and other such additional complications.

They're literally identical for most operations; you can use the very same instructions and the only difference is how you interpret the data. In x86 they set both carry and overflow flags so you can decide which one you care about.