Why is `scope` planned for deprecation?

[via Digitalmars-d]

On Tuesday, 18 November 2014 at 21:07:22 UTC, Walter Bright wrote:
> Those are not dedicated string instructions. Autoincrement was 
> an addressing mode that could be used with any register and any 
> instruction, including the stack and program counter (!).

Yes, Motorola 68000 also had those. Very useful combined with 
sentinels! ;^) It was one of those things that made the 68K asm 
feel a bit like a high level language.

> Autoincrement/autodecrement gave rise to *p++ and *p-- in C.

Might have, but not from PDP-11. It came to C from B which 
predated PDP-11.

> More than destroyed by every time you have to call strlen().

Don't!

And factor in the performance loss coming from reading from 
punched tape… ;-)

(Actually sentinels between fields are also better for recovery 
if you have data corruption in files, although there are many 
other solutions, but this is a non-problem today.)

> .TTYOUT is a macro that expands to code that calls the 
> operating system. The 11 doesn't have I/O instructions.

Ah, ok, so it was a system call.

> Uh, you need the length to determine when "the buffer is full".

For streaming: fixed size, modulo 2.

For allocating: worst case allocate, then release.

> Just try to manipulate paths, filenames, and extensions without 
> using strlen() and strcat(). Your claim that C string code 
> doesn't use strlen() is patently absurd.

No, I don't claim that I never used strlen(), but I never used 
strcat() IIRC, and never had the need to repeatedly call strlen() 
on long strings. Long strings would usually sit in a struct where 
there is space for a length. Slightly annoying, but not the big 
deal.

Filenames are easy, just allocate a large fixed size buffer, then 
fill in. open(). reuse buffer.

> Besides, you wouldn't be using javascript or python if 
> efficiency mattered.

Actually, lately most of my efficiency related programming is 
done in javascript!  I spend a lot of time breaking up javascript 
code into async calls to get good responsiveness. But most of my 
efficiency related problems are in browser engine layout-code 
(not javascript) that I have to work around somehow.

Javascript in isolation is getting insanely fast in the last 
generations of browser JITs. It is almost a bit scary, because 
that means that we might be stuck with it forever…