On 2015-10-15 16:28, Andrei Alexandrescu wrote:

> That may be worrisome. Any information on how many are using DWT, and
> how badly it would break if we pulled the change?
>
> If we assess there's too much breakage, we can define a DIP and make the
> check opt-in via a flag -dipNN.

I would like to add that the impact of a possible breakage depends on what the alternative is. If a function in Phobos or druntime is provided with the same functionality, then the breakage have less of an impact.

If D supported trailing delegate syntax (hint, hint) then it would be possible to have a library implementation with the exact same syntax. Although I guess there would be a conflict with the keyword during the deprecation phase.

-- 
/Jacob Carlborg

On Friday, 16 October 2015 at 06:26:30 UTC, Jacob Carlborg wrote:
> On 2015-10-15 16:28, Andrei Alexandrescu wrote:
>
>> That may be worrisome. Any information on how many are using DWT, and
>> how badly it would break if we pulled the change?
>>
>> If we assess there's too much breakage, we can define a DIP and make the
>> check opt-in via a flag -dipNN.
>
> I would like to add that the impact of a possible breakage depends on what the alternative is. If a function in Phobos or druntime is provided with the same functionality, then the breakage have less of an impact.

As far as I understand topic is about deprecating direct field access of synchronized classes, method calls in synhronized classes and `synchronized () {}` blocks will remain untouched.

On 2015-10-16 08:49, Dicebot wrote:

> As far as I understand topic is about deprecating direct field access of
> synchronized classes, method calls in synhronized classes and
> `synchronized () {}` blocks will remain untouched.

Yeah, that was the original topic. Then I interpreted it like all uses of "synchronized" would be deprecated.

Synchronized classes are not used in DWT.

-- 
/Jacob Carlborg

On 2015-10-16 08:49, Dicebot wrote:

> As far as I understand topic is about deprecating direct field access of
> synchronized classes, method calls in synhronized classes and
> `synchronized () {}` blocks will remain untouched.

Is it even possible to do synchronized classes in Java? That is, but synchronized on the class declaration as in D.

-- 
/Jacob Carlborg

On Friday, 16 October 2015 at 07:02:54 UTC, Jacob Carlborg wrote:
> On 2015-10-16 08:49, Dicebot wrote:
>
>> As far as I understand topic is about deprecating direct field access of
>> synchronized classes, method calls in synhronized classes and
>> `synchronized () {}` blocks will remain untouched.
>
> Is it even possible to do synchronized classes in Java? That is, but synchronized on the class declaration as in D.

I don't think so. synchronized is definitely for functions in Java and C# (and at the moment, D). synchronized classes like TDPL describes don't necessarily conflict with that, but they do force all of the functions in a class to be synchronized, whereas in Java or C#, only a portion of the class may care about or need synchronization. synchronized classes are certainly safer though, since they make it so that you can't get around the mutex without casting.

- Jonathan M Davis

On Friday, 16 October 2015 at 07:00:42 UTC, Jacob Carlborg wrote:
> Yeah, that was the original topic. Then I interpreted it like all uses of "synchronized" would be deprecated.

That would be really bold thing to do, I don't think anyone realistically proposes that. At most I'd suggest to explicitly mark it in spec / documentation as legacy and unidiomatic feature with no deprecation. Removing it does no benefit at this point (even if I believe it shouldn't have been there from the very start)

On Friday, 16 October 2015 at 14:07:44 UTC, Dicebot wrote:
> On Friday, 16 October 2015 at 07:00:42 UTC, Jacob Carlborg wrote:
>> Yeah, that was the original topic. Then I interpreted it like all uses of "synchronized" would be deprecated.
>
> That would be really bold thing to do, I don't think anyone realistically proposes that. At most I'd suggest to explicitly mark it in spec / documentation as legacy and unidiomatic feature with no deprecation. Removing it does no benefit at this point (even if I believe it shouldn't have been there from the very start)

It wouldn't have no benefit; it would simplify the language. But whether that simplification is worth the breakage it would cause is another matter. And I doubt that Walter and Andrei would go for the idea of deprecating synchronized at this point even if most of us were pushing them for it, because it would break existing code like DWT.

Certainly, if we were truly going to discuss deprecating synchronized, we'd have to figure out a way to even get Walter and Andrei to consider it, and I very much doubt that that is going to happen. It wouldn't surprise me if the simple fact that DWT exists would kill that proposal before Walter or Andrei even considered considering it.

- Jonathan M Davis

On 2015-10-16 16:07, Dicebot wrote:

> That would be really bold thing to do, I don't think anyone
> realistically proposes that. At most I'd suggest to explicitly mark it
> in spec / documentation as legacy and unidiomatic feature with no
> deprecation. Removing it does no benefit at this point (even if I
> believe it shouldn't have been there from the very start)

Ok, cool. DWT doesn't use synchronized classes so I don't really care :)

-- 
/Jacob Carlborg

On Friday, 16 October 2015 at 18:50:20 UTC, Jacob Carlborg wrote:
> On 2015-10-16 16:07, Dicebot wrote:
>
>> That would be really bold thing to do, I don't think anyone
>> realistically proposes that. At most I'd suggest to explicitly mark it
>> in spec / documentation as legacy and unidiomatic feature with no
>> deprecation. Removing it does no benefit at this point (even if I
>> believe it shouldn't have been there from the very start)
>
> Ok, cool. DWT doesn't use synchronized classes so I don't really care :)

Well, you probably will at some point, even if you don't know. According to TDPL, there's not supposed to be any such thing as a class with some functions which are synchronized and some not. The entire class is synchronized or none of it is, and if the class is synchronized then the member variables of the class are not accessible outside of the class. But that hasn't been implemented yet. Instead, we have synchronized functions like in Java. The PR that this thread is about makes it so that the member variables aren't accessible outside of the class, which probably won't cause DWT any problems, since public member variables are generally a bad idea. However, if this PR (or a future PR) actually finishes implementing synchronized classes (I don't know how far this PR actually goes), then any classes that DWT has which have any synchronized functions would then have to be synchronized classes. So, while the current PR may not break DWT, odds are that at some point in the future, synchronized classes will be finished, and DWT will probably break. It wouldn't surprise me if fixing it were fairly easy - particularly if DWT tends to synchronize all of the functions in a class when it synchronizes any of them - but at bare minimum, you're probably going to have to move the synchronized keyword from the function declarations to the class declaration, and it's possible that some of the implementation will have to change to cope with the fact that it's then not legal to have some functions in a class synchronized while others aren't.

- Jonathan M Davis

On Tuesday, 13 October 2015 at 11:51:02 UTC, ponce wrote:
> On Tuesday, 13 October 2015 at 10:57:55 UTC, Marco Leise wrote:
>>
>> Yep, I prefer to think it sets of variables that need mutex protection. And these are not generally the set of member fields in a class.
>
> Exactly. And that makes things using synchronized prone to longer and more frequent locks.

Yep. Labeling methods and classes as synchronized and shared is mostly for the sake of facilitating static analysis. But I think it comes at the cost of good program design. Beyond facilitating a direct port of Java code I don't know why you'd use synchronized at the method or class level.