On 2013-08-30 12:56, John Colvin wrote:

> alias this, but without implicit conversion. It just implements all the
> op**** functions (including opDispatch).

So what's the difference to Typedef, declared just below?

-- 
/Jacob Carlborg

On Friday, 30 August 2013 at 11:50:20 UTC, Jacob Carlborg wrote:
> On 2013-08-30 12:56, John Colvin wrote:
>
>> alias this, but without implicit conversion. It just implements all the
>> op**** functions (including opDispatch).
>
> So what's the difference to Typedef, declared just below?

Typedef uses Proxy to do the work. Proxy is a mixing template for adding in to a struct/class and Typedef is a very simple struct making use of it to implement a library typedef.

Unfortunately, Typedef is rather lacking as far as being a typedef is concerned, but that's not due to problems with Proxy.

On 2013-08-30 14:18, John Colvin wrote:

> Typedef uses Proxy to do the work. Proxy is a mixing template for adding
> in to a struct/class and Typedef is a very simple struct making use of
> it to implement a library typedef.
>
> Unfortunately, Typedef is rather lacking as far as being a typedef is
> concerned, but that's not due to problems with Proxy.

Ok, I see.

-- 
/Jacob Carlborg

On Friday, 30 August 2013 at 12:18:21 UTC, John Colvin wrote:
> On Friday, 30 August 2013 at 11:50:20 UTC, Jacob Carlborg wrote:
>> On 2013-08-30 12:56, John Colvin wrote:
>>
>>> alias this, but without implicit conversion. It just implements all the
>>> op**** functions (including opDispatch).
>>
>> So what's the difference to Typedef, declared just below?
>
> Typedef uses Proxy to do the work. Proxy is a mixing template for adding in to a struct/class and Typedef is a very simple struct making use of it to implement a library typedef.
>
> Unfortunately, Typedef is rather lacking as far as being a typedef is concerned, but that's not due to problems with Proxy.

What was the initial reason, to move typedef from the language into the library? I assume, that there is something special about typedef that can not be done with alias. If so, why was it moved?
It seems to be a trend, to move incomplete features from the language into the library (See also scope -> scoped). I do not like that. :/

On Friday, 30 August 2013 at 14:51:40 UTC, Namespace wrote:
> On Friday, 30 August 2013 at 12:18:21 UTC, John Colvin wrote:
>> On Friday, 30 August 2013 at 11:50:20 UTC, Jacob Carlborg wrote:
>>> On 2013-08-30 12:56, John Colvin wrote:
>>>
>>>> alias this, but without implicit conversion. It just implements all the
>>>> op**** functions (including opDispatch).
>>>
>>> So what's the difference to Typedef, declared just below?
>>
>> Typedef uses Proxy to do the work. Proxy is a mixing template for adding in to a struct/class and Typedef is a very simple struct making use of it to implement a library typedef.
>>
>> Unfortunately, Typedef is rather lacking as far as being a typedef is concerned, but that's not due to problems with Proxy.
>
> What was the initial reason, to move typedef from the language into the library? I assume, that there is something special about typedef that can not be done with alias. If so, why was it moved?
> It seems to be a trend, to move incomplete features from the language into the library (See also scope -> scoped). I do not like that. :/

I believe typedef was deprecated due to no-one being able to agree on the semantics (although it's a bit before my time). I think it needs to come back as a very simple concept:

A type duplication. e.g. typedef int myInt; (or typedef myInt = int;) creates a new type that is exactly identical to int, but is a distinct type in the type system.

It should provide *exactly* identical behaviour to e.g. having two structs with identical contents but different names. E.g.

struct A{}

typedef A tA;
alias A aA;
alias tA atA;
typedef aA taA;

assert(!is(tA == A));
assert(is(aA == A));
assert(is(atA == tA));
assert(!is(taA == atA));
etc....

It's a really basic feature that D ought to have.

> I believe typedef was deprecated due to no-one being able to agree on the semantics (although it's a bit before my time). I think it needs to come back as a very simple concept:
>
> A type duplication. e.g. typedef int myInt; (or typedef myInt = int;) creates a new type that is exactly identical to int, but is a distinct type in the type system.
>
> It should provide *exactly* identical behaviour to e.g. having two structs with identical contents but different names. E.g.
>
> struct A{}
>
> typedef A tA;
> alias A aA;
> alias tA atA;
> typedef aA taA;
>
> assert(!is(tA == A));
> assert(is(aA == A));
> assert(is(atA == tA));
> assert(!is(taA == atA));
> etc....
>
> It's a really basic feature that D ought to have.

I don't understand the difference to alias myInt = int;
Isn't it the same?

On 30/08/13 17:41, Namespace wrote:
> I don't understand the difference to alias myInt = int;
> Isn't it the same?

alias means it's a different name for the same type -- typedef should mean it's a different type with the same properties.

On Friday, 30 August 2013 at 15:41:55 UTC, Namespace wrote:
>> I believe typedef was deprecated due to no-one being able to agree on the semantics (although it's a bit before my time). I think it needs to come back as a very simple concept:
>>
>> A type duplication. e.g. typedef int myInt; (or typedef myInt = int;) creates a new type that is exactly identical to int, but is a distinct type in the type system.
>>
>> It should provide *exactly* identical behaviour to e.g. having two structs with identical contents but different names. E.g.
>>
>> struct A{}
>>
>> typedef A tA;
>> alias A aA;
>> alias tA atA;
>> typedef aA taA;
>>
>> assert(!is(tA == A));
>> assert(is(aA == A));
>> assert(is(atA == tA));
>> assert(!is(taA == atA));
>> etc....
>>
>> It's a really basic feature that D ought to have.
>
> I don't understand the difference to alias myInt = int;
> Isn't it the same?

see the first 2 asserts. alias doesn't create a new type, it just creates a new identifier for the old type.

A rough analogy: alias is by reference and typedef is by value

On Friday, 30 August 2013 at 15:41:55 UTC, Namespace wrote:
>> I believe typedef was deprecated due to no-one being able to agree on the semantics (although it's a bit before my time). I think it needs to come back as a very simple concept:
>>
>> A type duplication. e.g. typedef int myInt; (or typedef myInt = int;) creates a new type that is exactly identical to int, but is a distinct type in the type system.
>>
>> It should provide *exactly* identical behaviour to e.g. having two structs with identical contents but different names. E.g.
>>
>> struct A{}
>>
>> typedef A tA;
>> alias A aA;
>> alias tA atA;
>> typedef aA taA;
>>
>> assert(!is(tA == A));
>> assert(is(aA == A));
>> assert(is(atA == tA));
>> assert(!is(taA == atA));
>> etc....
>>
>> It's a really basic feature that D ought to have.
>
> I don't understand the difference to alias myInt = int;
> Isn't it the same?

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.

> 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.