On Fri, Aug 30, 2013 at 08:20:13PM +0200, Namespace wrote:
> >Typedef was useful not for poking around new type with same properties - new name of existing type, but for non-trivial default value:
> >
> >typedef int myint = 1;
> >
> >void main()
> >{
> >	myint my;
> >	assert(my is 1);
> >}
> >
> >Alias does not provide this feature, so D hadn't become better with this depreciation (actually the opposite). Nor it had with delete operator depreciation for the replacement of destroy, which like in case with typedef, does not cover full old feature functionality (and functionality what destroy() does provide is useless in many cases). I consider both depreciations as mistakes.
> 
> Thanks for explanation. I agree that the deprecation of typedef and delete is/was a mistake, and IMO the deprecation of scope and the library fix scoped is the same mistake.

What, scope is deprecated now? When did this happen, and how come I didn't hear about it?


T

-- 
Bare foot: (n.) A device for locating thumb tacks on the floor.

On 8/30/13 11:20 AM, Namespace wrote:
>> Typedef was useful not for poking around new type with same properties
>> - new name of existing type, but for non-trivial default value:
>>
>> typedef int myint = 1;
>>
>> void main()
>> {
>>     myint my;
>>     assert(my is 1);
>> }
>>
>> Alias does not provide this feature, so D hadn't become better with
>> this depreciation (actually the opposite). Nor it had with delete
>> operator depreciation for the replacement of destroy, which like in
>> case with typedef, does not cover full old feature functionality (and
>> functionality what destroy() does provide is useless in many cases). I
>> consider both depreciations as mistakes.
>
> Thanks for explanation. I agree that the deprecation of typedef and
> delete is/was a mistake, and IMO the deprecation of scope and the
> library fix scoped is the same mistake.

* typedef: it was so ill defined, bringing it any closer to sanity would've broken someone's code.

* delete: a festering dung of unsafety straight in the middle of the language. If there's enough argument that the functionality of delete is actually desirable we can always add a function for that.

* scope: cute and dangerous in equal proportions - great for a movie character, terrible for language design.


Andrei

On Fri, Aug 30, 2013 at 02:11:32PM -0700, Andrei Alexandrescu wrote:
> On 8/30/13 11:20 AM, Namespace wrote:
> >>Typedef was useful not for poking around new type with same properties - new name of existing type, but for non-trivial default value:
> >>
> >>typedef int myint = 1;
> >>
> >>void main()
> >>{
> >>    myint my;
> >>    assert(my is 1);
> >>}
> >>
> >>Alias does not provide this feature, so D hadn't become better with this depreciation (actually the opposite). Nor it had with delete operator depreciation for the replacement of destroy, which like in case with typedef, does not cover full old feature functionality (and functionality what destroy() does provide is useless in many cases). I consider both depreciations as mistakes.
> >
> >Thanks for explanation. I agree that the deprecation of typedef and delete is/was a mistake, and IMO the deprecation of scope and the library fix scoped is the same mistake.
> 
> * typedef: it was so ill defined, bringing it any closer to sanity would've broken someone's code.

Hmm. Is default values the only use case for typedefs? If so, we can already do it without:

	struct myint {
		int _impl = 1;
		alias _impl this;
	}
	myint x;
	assert(x==1);

Works on git HEAD.


> * delete: a festering dung of unsafety straight in the middle of the language. If there's enough argument that the functionality of delete is actually desirable we can always add a function for that.

Well, there's destroy, but last I heard, destroy has some pretty nasty issues on its own... (Not that I'd know anything about it, though, haven't needed to use it. Fortunately.)


> * scope: cute and dangerous in equal proportions - great for a movie character, terrible for language design.
[...]

What's so terrible about it?

And what other solution(s) are there? I only just found out about the library 'scoped' today, and apparently it isn't having a good time either.


T

-- 
PNP = Plug 'N' Pray

On 08/30/2013 11:43 PM, H. S. Teoh wrote:
>
>> >* scope: cute and dangerous in equal proportions - great for a movie
>> >character, terrible for language design.
> [...]
>
> What's so terrible about it?

I guess it is about the type system not (yet?) being expressive enough to make sure scoped class instances are not escaped.

On Friday, 30 August 2013 at 21:11:32 UTC, Andrei Alexandrescu wrote:
>
> * typedef: it was so ill defined, bringing it any closer to sanity would've broken someone's code.

I haven't heard about any specific troubles with typedef which are reason to depreciate the feature. In addition to typedef some other features are also experiencing troubles (shared, ref, properties, invariants,..) yet they are not deprecated.

> * delete: a festering dung of unsafety straight in the middle of the language.

It was useful to delete class objects at the time where programmer knew that he can delete safely to mitigate the problem of dangling references upon class finalization (by invoking dtor when objects are alive). Right now there is no way to do that. By the way, currently dmd accepts putting @safe attribute on class dtor definitions which access GC objects - this is a hole in @safety (accessing such elements is not a sufficient reason to be hole in safity, but not reseting pointers to null is).

> If there's enough argument that the functionality of delete is actually desirable we can always add a function for that.

Probably yes.

> * scope: cute and dangerous in equal proportions - great for a movie character, terrible for language design.
>
>
> Andrei

I cannot remember any feature implemented in phobos that was better then built-in language construct, including scope. Hasn't C++ followed the same policy and at the end it was considered as mistake? At least D has many built-in features comparing to C++ and this is advertized as an advantage.

On 8/30/13, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> * typedef: it was so ill defined, bringing it any closer to sanity would've broken someone's code.

So it had to be properly defined in the spec and implemented. Meanwhile we're fighting with the Phobos Typedef and it has way more problems right now, some of which will likely be unsolvable. Bug reports:

http://d.puremagic.com/issues/show_bug.cgi?id=10872 http://d.puremagic.com/issues/show_bug.cgi?id=10871 http://d.puremagic.com/issues/show_bug.cgi?id=10778 http://d.puremagic.com/issues/show_bug.cgi?id=8618 http://d.puremagic.com/issues/show_bug.cgi?id=7777 http://d.puremagic.com/issues/show_bug.cgi?id=7737

> * scope: cute and dangerous in equal proportions - great for a movie character, terrible for language design.

scoped() has its own quirks, for example: http://d.puremagic.com/issues/show_bug.cgi?id=4636 http://d.puremagic.com/issues/show_bug.cgi?id=5115 http://d.puremagic.com/issues/show_bug.cgi?id=10921

And this last bug that was filed (10921) was a bug that was known since 2010: http://d.puremagic.com/issues/show_bug.cgi?id=5115#c6

So 3 years later, and it's still an issue. I don't even see how Issue 4636 can even be fixed, there's no way for a template in another module to get private access to the class constructor.

---

Anyway, we've deprecated old keywords, and introduced half-implemented library replacements. I don't see how we stand any better today than we did before.

On 2013-08-31 11:46, Andrej Mitrovic wrote:

> So 3 years later, and it's still an issue. I don't even see how Issue
> 4636 can even be fixed, there's no way for a template in another
> module to get private access to the class constructor.

A delegate/function pointer will bypass the protection.

-- 
/Jacob Carlborg

On 8/31/13, Jacob Carlborg <doob@me.com> wrote:
> A delegate/function pointer will bypass the protection.

How will you pass a pointer to a constructor?

On 8/30/13 9:55 PM, Maxim Fomin wrote:
> On Friday, 30 August 2013 at 21:11:32 UTC, Andrei Alexandrescu wrote:
>>
>> * typedef: it was so ill defined, bringing it any closer to sanity
>> would've broken someone's code.
>
> I haven't heard about any specific troubles with typedef which are
> reason to depreciate the feature.

The problem is nobody could agree whether typedef was a supertype or a subtype of its original type. It was just a bizarre teratoma grown by happenstance.

> In addition to typedef some other
> features are also experiencing troubles (shared, ref, properties,
> invariants,..) yet they are not deprecated.

That's not an argument.

>> * delete: a festering dung of unsafety straight in the middle of the
>> language.
>
> It was useful to delete class objects at the time where programmer knew
> that he can delete safely to mitigate the problem of dangling references
> upon class finalization (by invoking dtor when objects are alive). Right
> now there is no way to do that. By the way, currently dmd accepts
> putting @safe attribute on class dtor definitions which access GC
> objects - this is a hole in @safety (accessing such elements is not a
> sufficient reason to be hole in safity, but not reseting pointers to
> null is).

That would be a bug.

>> If there's enough argument that the functionality of delete is
>> actually desirable we can always add a function for that.
>
> Probably yes.
>
>> * scope: cute and dangerous in equal proportions - great for a movie
>> character, terrible for language design.
>>
>>
>> Andrei
>
> I cannot remember any feature implemented in phobos that was better then
> built-in language construct, including scope. Hasn't C++ followed the
> same policy and at the end it was considered as mistake?

Not sure I understand.

> At least D has
> many built-in features comparing to C++ and this is advertized as an
> advantage.

I don't think that's how I see things.


Andrei

On 8/31/13 2:46 AM, Andrej Mitrovic wrote:
> On 8/30/13, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>> * typedef: it was so ill defined, bringing it any closer to sanity
>> would've broken someone's code.
>
> So it had to be properly defined in the spec and implemented.
> Meanwhile we're fighting with the Phobos Typedef and it has way more
> problems right now, some of which will likely be unsolvable. Bug
> reports:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=10872
> http://d.puremagic.com/issues/show_bug.cgi?id=10871
> http://d.puremagic.com/issues/show_bug.cgi?id=10778
> http://d.puremagic.com/issues/show_bug.cgi?id=8618
> http://d.puremagic.com/issues/show_bug.cgi?id=7777
> http://d.puremagic.com/issues/show_bug.cgi?id=7737

Most of these look approachable, and there are workarounds for the others. Granted, the UDT can't be made 100% like the old typedef (and probably that would be bad, too :o)).

>> * scope: cute and dangerous in equal proportions - great for a movie
>> character, terrible for language design.
>
> scoped() has its own quirks, for example:
> http://d.puremagic.com/issues/show_bug.cgi?id=4636
> http://d.puremagic.com/issues/show_bug.cgi?id=5115
> http://d.puremagic.com/issues/show_bug.cgi?id=10921
>
> And this last bug that was filed (10921) was a bug that was known since 2010:
> http://d.puremagic.com/issues/show_bug.cgi?id=5115#c6
>
> So 3 years later, and it's still an issue. I don't even see how Issue
> 4636 can even be fixed, there's no way for a template in another
> module to get private access to the class constructor.
>
> ---
>
> Anyway, we've deprecated old keywords, and introduced half-implemented
> library replacements. I don't see how we stand any better today than
> we did before.

Library issues are a lot easier to deal with than core language issues.


Andrei