Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix Issue 17045 - deprecate main(char[][]) argument check #6387

Closed
wants to merge 1 commit into from

Conversation

WalterBright
Copy link
Member

It was a leftover from D1 daze, the check is now proper D2.

@WalterBright WalterBright force-pushed the main-check branch 3 times, most recently from 088f736 to 19e36e8 Compare December 29, 2016 16:46
@WalterBright
Copy link
Member Author

Looks like I need to deprecate the old way.

@WalterBright WalterBright changed the title make main() check nicer deprecate main(char[][]) argument check Dec 29, 2016
@WalterBright WalterBright force-pushed the main-check branch 4 times, most recently from 9422802 to 97254f5 Compare December 30, 2016 17:28
@WalterBright WalterBright changed the title deprecate main(char[][]) argument check fix Issue 17045 - deprecate main(char[][]) argument check Dec 30, 2016
Copy link
Member

@andralex andralex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eh, I didn't mind that I had the option to change the input... what is bad about this?

if (t.ty == Tarray && t.nextOf().ty == Tarray && t.nextOf().nextOf().ty == Tchar)
deprecation("use main(string[]) instead of main(char[][])");
else
argerr = true;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not covered

if (!tf.nextOf())
error("must return int or void");
else if (tf.nextOf().ty != Tint32 && tf.nextOf().ty != Tvoid)
error("must return int or void, not %s", tf.nextOf().toChars());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not covered

@WalterBright
Copy link
Member Author

WalterBright commented Jan 3, 2017

  1. it's not documented to be mutable
  2. druntime assumes it is not mutated
  3. seems to me that mutating it is a pretty dubious practice, violating encapsulation

@andralex
Copy link
Member

andralex commented Jan 3, 2017

it's not documented to be mutable

We could move the matter as a bug in the documentation.

druntime assumes it is not mutated

That is interesting. How? Where?

seems to me that mutating it is a pretty dubious practice, violating encapsulation

I would agree for a general function, but main is special because it is the entry point in the application, and returning from main ends the application.

@andralex
Copy link
Member

andralex commented Jan 3, 2017

cc @MartinNowak to weigh in on the deprecation process

@WalterBright
Copy link
Member Author

WalterBright commented Jan 3, 2017

main's arguments can come from anywhere, like a string from the operating system. Mutating strings like that is just not a good idea. There many be multithreading issues.

I don't see a reasonable use case for mutating them. Making the mutable is an additional constraint on the caller - and for what purpose?

@WalterBright
Copy link
Member Author

Replaced with #6399

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants