On 08/19/2010 11:42 AM, SHOO wrote:
> (2010/08/20 0:29), Andrei Alexandrescu wrote:
> It is a destructive change to deprecated scope and needs mass code
> renewal. What of present scope are you dissatisfied with? The evolution
> that expands present scope if possible is the best.
> scope pays the sacrifice and what does get?
>
> I want the page that summarize function/features/modules and reasons examining the abolition.

We don't have a formal document yet, though the matter is pretty clear to us. Consider:

class X {
    ...
    void method() { ... }
}

void fun() {
   scope x = new X;
   x.method();
}

Now consider what steps you need to make sure that the code is safe. Essentially x must not escape the scope of foo(). But x is passed inside method() as "this". So the compiler must make sure that method() does not escape "this". But then method() may call other functions and pass "this" to them, or may not even be available to the compiler at the point where scope is used. This is an unsolvable problem without making extensive changes to the language.

As I'm sure you know we're trying to help the matter with library-based approaches, but leaving straight in the language a feature that is impossible to make safe is not admissible. Walter and I agree that scope must be abolished.


Andrei

On Thu, 19 Aug 2010, Andrei Alexandrescu wrote:
> 
> As I'm sure you know we're trying to help the matter with library-based approaches, but leaving straight in the language a feature that is impossible to make safe is not admissible. Walter and I agree that scope must be abolished.

Cast and union can't be made safe either.. should they be removed?  Why not push scope out of the safed subset and leave the tool around where it's useful?

On 08/19/2010 09:47 PM, Brad Roberts wrote:
> On Thu, 19 Aug 2010, Andrei Alexandrescu wrote:
>>
>> As I'm sure you know we're trying to help the matter with library-based approaches, but leaving straight in the language a feature that is impossible to make safe is not admissible. Walter and I agree that scope must be abolished.
>
> Cast and union can't be made safe either.. should they be removed?  Why not push scope out of the safed subset and leave the tool around where it's useful?

Cast and union must stay primitives because they can't be done in a library. I'd remove them if I could, but doing so would strictly reduce the language's power.

Andrei

On 8/19/2010 11:44 PM, Andrei Alexandrescu wrote:
> On 08/19/2010 09:47 PM, Brad Roberts wrote:
>> On Thu, 19 Aug 2010, Andrei Alexandrescu wrote:
>>>
>>> As I'm sure you know we're trying to help the matter with library-based
>>> approaches, but leaving straight in the language a feature that is
>>> impossible
>>> to make safe is not admissible. Walter and I agree that scope must be
>>> abolished.
>>
>> Cast and union can't be made safe either.. should they be removed?  Why not push scope out of the safed subset and leave the tool around where it's useful?
>
> Cast and union must stay primitives because they can't be done in a library. I'd remove them if I could, but doing so would strictly reduce the language's power.
>
> Andrei
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
Well, if you have unions you could probably do casts in a library.  I'm not saying we should do this, just that it's possible.  For example:

U cast(T)(T ptr) if(isPointer!T && isPointer!U) {
     union U {
          T t;
          U u;
     }

     U myUnion;
     myUnion.t = ptr;
     return myUnion.u;
}

> Well, if you have unions you could probably do casts in a library. I'm not saying we should do this, just that it's possible. For example:
>
> U cast(T)(T ptr) if(isPointer!T && isPointer!U) {
> union U {
> T t;
> U u;
> }
>
> U myUnion;
> myUnion.t = ptr;
> return myUnion.u;
> }

It's a good point, but that's only for certain cases of reinterpret cast. Object casts and in particular interface-to-Object and other cross-casts won't work that way.

Andrei

> We don't have a formal document yet, though the matter is pretty clear to us. Consider:
>
> class X {
> ...
> void method() { ... }
> }
>
> void fun() {
> scope x = new X;
> x.method();
> }
>
> Now consider what steps you need to make sure that the code is safe. Essentially x must not escape the scope of foo(). But x is passed inside method() as "this". So the compiler must make sure that method() does not escape "this". But then method() may call other functions and pass "this" to them, or may not even be available to the compiler at the point where scope is used. This is an unsolvable problem without making extensive changes to the language.
>
> As I'm sure you know we're trying to help the matter with library-based approaches, but leaving straight in the language a feature that is impossible to make safe is not admissible. Walter and I agree that scope must be abolished.
>
>
> Andrei

I understand it well. Thank you.
When is it going to mark deprecated? D3?
I think that you had better announce it as soon as possible.

On Friday 20 August 2010 02:04:21 SHOO wrote:
> I understand it well. Thank you.
> When is it going to mark deprecated? D3?
> I think that you had better announce it as soon as possible.

Well, with pretty much everything scheduled for deprecation, it's been mentioned on the D list from time to time, but since there is no list anywhere saying which language features are scheduled for deprecation, there's not really any way to know for sure. The fact that so much of the documentation is out of date doesn't help either.

- Jonathan M Davis

(2010/08/20 0:08), Andrei Alexandrescu wrote:
> On 08/18/2010 12:21 PM, SHOO wrote:
>> (2010/08/18 20:18), Andrei Alexandrescu wrote:
>>> Line 94 and others: you have a fair amount of @system methods that are very @safe. Why mark them as @system? I think the entire module is @safe in fact.
>>>
>>
>> The reason is because it does a calculation to lose precision. I do not yet understand it about @safe/@trusted/@system well.
>
> Their implementation is still under flux, but until then, we can't use them as a matter of preference. You may want to eliminate them entirely (or comment them out for now), or try to compile the entire module with @safe: at the top and report every compiler error as a bug. In particular, explicit casting from real to long is entirely safe and should not be an error.
>
>> How about:
>> T toSeconds(T=real)() if (isNumeric!T) {
>> return (cast(T)value)/TICKSPERSEC;
>> }
>> @property alias toSeconds!real seconds;
>
> I think that should work.
>
>>> Line 318: return cast(int) (value - t.value);
>>>
>>
>> No. value is long, it cannot cast to int.
>> Check this:
>>
>> import std.stdio;
>> void main()
>> {
>> long l1 = 0x1000000000000001L;
>> long l2 = 0x4000000000000000L;
>> writeln(l1); // 1152921504606846977
>> writeln(l2); // 4611686018427387904
>> writeln(l1 - l2); // -3458764513820540927
>> writeln(cast(int)(l1 - l2)); // 1 <- !!!!
>> }
>
> Ha, thanks for the lesson.
>
>>> Line 414: no need for @trusted, casting numbers is not unsafe.
>>>
>>
>> Error: cast from const(long) to real not allowed in safe code
>
> Compiler bug. I wonder whether const has anything to do with (shouldn't).
>
>> The struct does not have a default constructer. This class must
>> initialize it by all means in runtime. Because this class is a final
>> class, nothing has override functions. This means that it can show the
>> best performance by optimization.
>> There are not advantages with using struct that sacrifice the secure
>> initialization.
>
> Oh, I missed that the class is final. Thanks. The sad reality is that classes will end up using dynamic allocation, which would cost much more than inserting one check in each of your four primitives.
>
>> If there is even a default constructer, I will use a struct.
>> I discussed even an argument of before, I really want the default
>> constructer for struct.
>
> I would like it too.
>
>> It's my understanding that there are two reasons why a struct doesn't
>> have a default constructer toward.
>> Primarily, it can define as a variable without minding an initialization
>> method in particular generic programming.
>> Second, it ensure the initialization that resource assignment does not
>> occur.
>> See also: http://j.mp/9KGTFd
>
> Unfortunately that won't help this case because we can't call system APIs during compilation.
>
>> Cannot these be settled by making templates such as hasDefaultConstructor!T and canMakeStaticVariable!T ?
>
> It's possible, but then we'd have structs impossible to clear. Alternatively, we should accept that cleared structs only have the .init values set for their members.
>
>>> Line 489: if we go with a struct design, we should have a constructor that "autostarts" a StopWatch, e.g.:
>>>
>>> auto myWatch = StopWatch(AutoStart.yes);
>>>
>>
>> I examine.
>
> Leaving aside all struct-related issues, I really think it's entirely reasonable to have the default constructor of a stopwatch leave it in the "not started" state. The C++ stopwatches we use at Facebook (which I think are inspired by Boost) need to be explicitly initialized like this:
>
> Timer timer;
> timer.start();
>
> or like this:
>
> Timer timer(true);
>
> I didn't hear many protests about that setup. So why not do the same? By default there's no system call, so you can create an array of Stopwatch objects without incurring a large cost. Then you start them manually as you find fit.
>
>> One question: Is there the reason using enum? Should not it be bool?
>> auto myWatch = StopWatch(true);
>
> Ha! Good question. Many people consider passing options as Booleans a poor design (the design of Facebook's Timer above notwithstanding :o)). This is because most of the time the reader must look up the manual to see what the meaning of "true" or "false" is. Just search std/ for the string ".yes" and you'll see for example that I don't use true and false for case sensitive, I use CaseSensitive.no or CaseSensitive.yes. It would be really difficult for a reader to figure what indexOf(str1, str2, true) is, but indexOf(str1, str2, CaseSensitive.yes) is very easy to understand.
>
>
> Andrei

I rewrote:
http://ideone.com/5IgYU
How about it?

P.S. I used an immutable struct for the first time...

On 08/20/2010 04:04 AM, SHOO wrote:
> I understand it well. Thank you.
> When is it going to mark deprecated? D3?
> I think that you had better announce it as soon as possible.

Walter?

TDPL doesn't even mention it.

Andrei

(2010/08/20 19:35), SHOO wrote:
> I rewrote:
> http://ideone.com/5IgYU
> How about it?
>
> P.S. I used an immutable struct for the first time...

Oops, I forgot AUTOSTART.
http://ideone.com/GiVmf
AutoStart.yes seems to be slightly redundant.
How about making a special type AutoStart with typedef and a AUTOSTART
with constant value(enum)?
See also: Line415, Line469, Line474-487