scope() statements and return

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Fri Oct 3 23:09:39 PDT 2014


On Sat, Oct 04, 2014 at 01:08:38AM -0400, Shammah Chancellor via Digitalmars-d wrote:
> On 2014-10-03 19:35:31 +0000, Andrei Alexandrescu said:
[...]
> >>Worse yet:
> >>
> >>	// What does this function do? What *should* it do??
> >>	int func() {
> >>		scope(success)
> >>			throw new Exception("");
> >>		scope(failure)
> >>			return 1;
> >>		return 0;
> >>	}
> >
> >1
> 
> This throws an exception, as it's already outside of the
> scope(failure) block and into the finally for success;
[...]

And if you switched the two scope statements?

I think you guys are missing the point... The point is that it's
ridiculous for the function to return one thing, only for the scope
statement to modify that return value after the fact in a way that
totally obfuscates the code.

	int func() {
		lots();
		of();
		scope(exit) return 1;
		code();
		inBetween();

		// What does this function return? Yes, "obviously" it
		// returns 1. Right.
		return 0;
	}

Similarly, allowing scope to do arbitrary things will easily turn your
loops into spaghetti code:

	foreach (i; 0 .. 10)
	{
		scope(exit) break;
		scope(success) continue;
		if (i==5)
			break;
			// Yeah right, this doesn't actually break
			// (even though it's totally broken :-P)

		scope(failure) return;
		if (i==8)
			throw new Exception();
			// Yeah right, this is just a dainbramaged way
			// of breaking the loop
	}
	writeln("You know I actually get run?");

The only use of allowing these disruptive flow control constructs in
scope statements, that I can see, is to facilitate in writing entries
for the International Obfuscated D Code Contest.


T

-- 
Маленькие детки - маленькие бедки.


More information about the Digitalmars-d mailing list