Bug 12615 – Warn against, and then deprecate old alias syntax

Now we have the syntax: alias T = int; So this syntax should give a warning, later a deprecation message, and later an error: alias int T; (The "alias this" syntax must be kept, it's for another purpose.)

A prerequisite to this would be to replace all occurrences of the old syntax in DRuntime and Phobos with the new syntax.

(In reply to Mike from comment #1) > A prerequisite to this would be to replace all occurrences of the old syntax > in DRuntime and Phobos with the new syntax. Right. And the warning will help find all those occurrences.

"dscanner --styleCheck" will find them for you. https://github.com/Hackerpilot/Dscanner/

The issue with doing this is that there are still quite a few syntax constructs that the new syntax doesn't currently support, including alias this.

(In reply to Orvid King from comment #4) > The issue with doing this is that there are still quite a few syntax > constructs that the new syntax doesn't currently support, including alias > this. Yes, "alias this" is essentially a different syntax, and it will be kept, as said in the first message of this thread. What other constructs are a problem for the warn against the old alias syntax?

(In reply to bearophile_hugs from comment #5) > What other constructs are a problem for the warn against the old alias > syntax? Function pointers. There's an issue where 'alias f = extern(C) void function()' does not work (it's a filed bug). Until that is fixed we can't plan to go forward with this warning. I would also argue that we should start developing a D porting tool that auto-converts the old alias syntax to the new one. It should be trivial to implement and should get rid of the nuisance of manually fixing code.

This is an enhancement, as it is currently working as designed.

(In reply to Andrej Mitrovic from comment #6) > (In reply to bearophile_hugs from comment #5) > > What other constructs are a problem for the warn against the old alias > > syntax? > > Function pointers. There's an issue where 'alias f = extern(C) void > function()' does not work (it's a filed bug). Until that is fixed we can't > plan to go forward with this warning. I filed it as the issue 12802.

Probably leave multialias declaration valid, it's quite handy: alias HANDLE BCRYPT_HANDLE, BCRYPT_ALG_HANDLE, BCRYPT_KEY_HANDLE, BCRYPT_HASH_HANDLE, BCRYPT_SECRET_HANDLE;

(In reply to Sobirari Muhomori from comment #9) > Probably leave multialias declaration valid, it's quite handy: > alias HANDLE BCRYPT_HANDLE, BCRYPT_ALG_HANDLE, BCRYPT_KEY_HANDLE, > BCRYPT_HASH_HANDLE, BCRYPT_SECRET_HANDLE; I didn't know this syntax is valid. I think having to define multiple aliases is not a common need. But if we keep the multialias declaration syntax, then I think we should keep the single alias syntax too.

(In reply to Sobirari Muhomori from comment #9) > Probably leave multialias declaration valid, it's quite handy: > alias HANDLE BCRYPT_HANDLE, BCRYPT_ALG_HANDLE, BCRYPT_KEY_HANDLE, > BCRYPT_HASH_HANDLE, BCRYPT_SECRET_HANDLE; What does that even do?

(In reply to briancschott from comment #11) > What does that even do? If I understand correctly, it aliases all the items in the list to HANDLE. FWIW, I don't think the syntax is worth keeping.

Has ever even been officially decided that the old alias syntax is going away? Personally, I'd hate to see it go, and the fact that the new syntax doesn't work in all of the places that the old syntax works makes it that much worse to use the new one IMHO. The resulting inconsistency is highly confusing.

(In reply to Sobirari Muhomori from comment #9) > Probably leave multialias declaration valid, it's quite handy: > alias HANDLE BCRYPT_HANDLE, BCRYPT_ALG_HANDLE, BCRYPT_KEY_HANDLE, > BCRYPT_HASH_HANDLE, BCRYPT_SECRET_HANDLE; I believe that can be done with the 'new' syntax as... alias BCRYPT_HANDLE = HANDLE; alias BCRYPT_ALG_HANDLE = HANDLE; alias BCRYPT_KEY_HANDLE = HANDLE; alias BCRYPT_HASH_HANDLE = HANDLE; alias BCRYPT_SECRET_HANDLE = HANDLE; ... which despite its verbosity, I actually prefer. (In reply to Jonathan M Davis from comment #13) > Has ever even been officially decided that the old alias syntax is going > away? Personally, I'd hate to see it go, and the fact that the new syntax > doesn't work in all of the places that the old syntax works makes it that > much worse to use the new one IMHO. The resulting inconsistency is highly > confusing. One of them needs to go, and I prefer that the 'old' syntax go and the '=' syntax remains. (In reply to Andrej Mitrovic from comment #6) > Function pointers. There's an issue where 'alias f = extern(C) void > function()' does not work (it's a filed bug). Until that is fixed we can't > plan to go forward with this warning. What's the issue number for this?

> (In reply to Andrej Mitrovic from comment #6) > > Function pointers. There's an issue where 'alias f = extern(C) void > > function()' does not work (it's a filed bug). Until that is fixed we can't > > plan to go forward with this warning. > > What's the issue number for this? Scratch that. I see it is issue 12802, and appears to have been addressed. Cool!

(In reply to Mike from comment #14) > > One of them needs to go, I disagree. Don't break all of my old code for no reason.

(In reply to yebblies from comment #16) > I disagree. Don't break all of my old code for no reason. There is a reason, to remove dead wood, and reduce the number of different ways to do something in D, making the language more lean. The question is if this outweighs the costs of changing code. I think the balance is still for deprecating unnecessary parts.

I think that either using the old syntax should be considered to be just fine, and we should stop trying to push the new syntax on people any more than we push while(1) over for(;;), or we should just deprecate the old syntax and move on. There have been recent pushes to remove uses of the old syntax from druntime and Phobos, and almost everyone seems to be in favor of using the new syntax exclusively. Personally, I prefer the old syntax, but I'm clearly in the minority, and we're just going to end up with arguments over whether anyone should use the older syntax if we keep it around. If such a large percentage of the D developers are in favor of the newer syntax and against anyone using the older syntax (as appears to be the case), we might as well just get rid of the old one, since retaining it just causes confusion and debate without adding functionality. The only real cost is the annoyance of having to change code at some point after the deprecation is in place. And dfix is now able to replace all uses of the old syntax with the new syntax for you, so updating existing code would be trivial. And deprecation doesn't break code anyway. It just warns people that the code will be broken at some point in the future (the messages can be annoying if there are a lot of them, but the code continues to work exactly as it did before). So arguably, we really should either just deprecate the old syntax and move on or put a notice in the changelog that we're planning to do so and then actually deprecate it in a release or two.

I think, this is controversial after all. 1. alias this does use C syntax, so deprecation would contradict it - effectively kills this request 2. there was an argument for brevity in D, so multiple alias declaration can be seen as an asset 3. dscanner can check code style for those who really want it

The only reason `alias whetever this` does not use the assignment syntax is that the `alias this = existingname` conflicts with the ability to alias base (i.e. super class) constructors: `alias this = super.this`. Find a solution to that and we can finally use the assignment syntax for alias this. See discussions at https://github.com/dlang/dlang.org/pull/200 and https://github.com/dlang/dmd/pull/1341 for greater understanding of the issue.

(In reply to Mike Franklin from comment #20) > Find a solution to that and we can finally use the assignment syntax for alias > this. A proposal to resolve the issue was presented at https://github.com/dlang/dmd/pull/1341#issuecomment-34845297

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18818 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB