Currently the accepted signatures for the D main are (it also works if you use "pure main"):

void main();
int main();
void main(string[] args);
int main(string[] args);

But why instead isn't the args argument const when present?
int main(in string[] args);

Bye,
bearophile

On Fri, 12 Aug 2011 16:16:45 -0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Currently the accepted signatures for the D main are (it also works if you use "pure main"):
>
> void main();
> int main();
> void main(string[] args);
> int main(string[] args);
>
> But why instead isn't the args argument const when present?
> int main(in string[] args);

What would be the purpose of this?

-Steve

Steven Schveighoffer:

> > int main(in string[] args);
> 
> What would be the purpose of this?

Why do you use "in" in function arguments? To make sure you will not modify the given array. I think it's not good practice to change the length of the input strings of the main or replace it with another dynamic array at runtime.

On the other hand in D const is transitive, and currently you can't do many things on a const array (like several std.algorithms). So currently that "in" restricts too much the things you are allowed to do with args. This is why I have asked for an opinion, to understand the balance of the pros and cons.

Bye,
bearophile

That's pretty stupid, of course you want to modify the arguments.

Classic example:

void main(string[] args)
{
    args.popFront;  // get rid of name

    foreach (arg; args)
    {
    }
}

On Friday, August 12, 2011 15:51 Andrej Mitrovic wrote:
> That's pretty stupid, of course you want to modify the arguments.
> 
> Classic example:
> 
> void main(string[] args)
> {
> args.popFront; // get rid of name
> 
> foreach (arg; args)
> {
> }
> }

getopt alters the arguments too. I'm not sure that it should be disallowed to use

void main(in string[] args)

but I'd argue that doing that is generally incredibly counter-productive. Of course, I'm against the use of in with arrays in general. const(T)[] maybe, but as soon as you use in, you can't use any range functions. A totally const or immutable array is generally useless IMHO.

- Jonathan M Davis

Jonathan M Davis wrote:
> const(T)[] maybe,
> but as soon as you use in, you can't use any range functions.

That is, to me, the biggest problem with range functions and something that should be fixed.

There's no defense for it aside from being the status quo. It's just a shortcoming of the current implementation, not a principled limitation.

On 08/13/2011 01:04 AM, Adam Ruppe wrote:
> Jonathan M Davis wrote:
>> const(T)[] maybe,
>> but as soon as you use in, you can't use any range functions.
>
> That is, to me, the biggest problem with range functions and
> something that should be fixed.
>
> There's no defense for it aside from being the status quo. It's just a
> shortcoming of the current implementation, not a principled limitation.

+1. Maybe the impact on Phobos of fixing this can be kept small by a well thought-out language change.

On Friday, August 12, 2011 16:04 Adam Ruppe wrote:
> Jonathan M Davis wrote:
> > const(T)[] maybe,
> > but as soon as you use in, you can't use any range functions.
> 
> That is, to me, the biggest problem with range functions and something that should be fixed.
> 
> There's no defense for it aside from being the status quo. It's just a shortcoming of the current implementation, not a principled limitation.

If it can be fixed so that a slice of a const/immutable range is tail-const, then they'll be in the same boat as static arrays and at least be usable with range-based functions when you slice them, but at this point, the only way to make it so that you could simply pass them without slicing them is if you overloaded _every_ range-based functions on arrays. And since you're going to have to slice containers to pass them to range-based functions anyway (dynamic arrays are actually kind of weird in that they can be passed directly to range-based functions without slicing them - it's just that they're the most common used of ranges and therefore what we're most used to). So, I don't think that it's unreasonable to require that static arrays and const or immutable dynamic arrays be sliced to be used with range-based functions. But until it's fixed so that slices of a dynamic range are tail-const/tail- immutable instead of exactly the same type, that doesn't work with const or immutable dynamic arrays, which definitely sucks. But if that can be fixed, I think that the situation will then be fairly reasonable.

- Jonathan M Davis

Andrej Mitrovic:

> void main(string[] args)
> {
>     args.popFront;  // get rid of name
> 
>     foreach (arg; args)
>     {
>     }
> }

If I see code like that I probably rewrite it like this:

void main(in string[] args) {
    foreach (arg; args[1..$]) {
    }
}

;-)

Bye,
bearophile

On 8/13/11, bearophile <bearophileHUGS@lycos.com> wrote:
> Andrej Mitrovic:
>
>> void main(string[] args)
>> {
>>     args.popFront;  // get rid of name
>>
>>     foreach (arg; args)
>>     {
>>     }
>> }
>
> If I see code like that I probably rewrite it like this:
>
> void main(in string[] args) {
>     foreach (arg; args[1..$]) {
>     }
> }
>

And what benefit is there to that? I pop the argument and then don't have to worry about it ever again. Whereas you're using [1..$], and later on in your argument parsing code you might introduce a bug like:

auto userArgumentCount = args.length; // woops, you'll get 1 extra here due to app name.