It would be nice to permit something like this:

struct Foo {
    this(int x, string y) { ... }
    this(string y) => this(0, y);
}

Currently this fails because constructors are not allowed to return anything.  But that should not be part of this DIP, probably.

On Friday, 4 February 2022 at 11:21:48 UTC, Elronnd wrote:
> It would be nice to permit something like this:
>
> struct Foo {
>     this(int x, string y) { ... }
>     this(string y) => this(0, y);
> }
>
> Currently this fails because constructors are not allowed to return anything.  But that should not be part of this DIP, probably.

The implementation as done by Adam is done in the parser but if I move it down the stack a bit this is probably doable.

On Friday, 4 February 2022 at 12:40:32 UTC, max haughton wrote:
> On Friday, 4 February 2022 at 11:21:48 UTC, Elronnd wrote:
>> It would be nice to permit something like this:
>>
>> struct Foo {
>>     this(int x, string y) { ... }
>>     this(string y) => this(0, y);
>> }
>>
>> Currently this fails because constructors are not allowed to return anything.  But that should not be part of this DIP, probably.
>
> The implementation as done by Adam is done in the parser but if I move it down the stack a bit this is probably doable.

Please don't. Having `=> expr` be simple syntax sugar for `{ return expr; }` is consistent and easy to understand. We don't need to add special cases just to save a *single character*:

    this(string y) => this(0, y);
    this(string y) { this(0, y); }

On Friday, 4 February 2022 at 14:46:39 UTC, Paul Backus wrote:
> On Friday, 4 February 2022 at 12:40:32 UTC, max haughton wrote:
>> On Friday, 4 February 2022 at 11:21:48 UTC, Elronnd wrote:
>>> [...]
>>
>> The implementation as done by Adam is done in the parser but if I move it down the stack a bit this is probably doable.
>
> Please don't. Having `=> expr` be simple syntax sugar for `{ return expr; }` is consistent and easy to understand. We don't need to add special cases just to save a *single character*:
>
>     this(string y) => this(0, y);
>     this(string y) { this(0, y); }

I am going to move it down the stack for implementation reasons (syntax reproduction and error messages) anyway but point taken.

On 04.02.22 18:18, Tejas wrote:
> On Friday, 4 February 2022 at 14:46:39 UTC, Paul Backus wrote:
>> On Friday, 4 February 2022 at 12:40:32 UTC, max haughton wrote:
>>> On Friday, 4 February 2022 at 11:21:48 UTC, Elronnd wrote:
>>>> It would be nice to permit something like this:
>>>>
>>>> struct Foo {
>>>>     this(int x, string y) { ... }
>>>>     this(string y) => this(0, y);
>>>> }
>>>>
>>>> Currently this fails because constructors are not allowed to return anything.  But that should not be part of this DIP, probably.
>>>
>>> The implementation as done by Adam is done in the parser but if I move it down the stack a bit this is probably doable.
>>
>> Please don't. Having `=> expr` be simple syntax sugar for `{ return expr; }` is consistent and easy to understand.

Yes, no need to change the implementation of this feature, just fix semantic analysis of constructors.

>> We don't need to add special cases just to save a *single character*:
>> ...

Sure, but actually, the fact that the example code does not already work with the current implementation of the feature is the special case. There is even less need to add special cases just so people have to waste an additional character. (Plus some white space, by the way, at least outside of personal projects. There may be strict style guidelines.)

>>     this(string y) => this(0, y);
>>     this(string y) { this(0, y); }
> ...

If you have to violate common style guidelines in order to support a claim that the status quo is not so much worse, then probably the new syntax is actually significantly better. (Razvan did the same in the feedback thread, I don't get why people are doing this. Would this really fly, e.g., in Phobos?)

> Actually, the following compiles:
> ```d
> void funcc()
> {
> }
> 
> void func()
> {
>      return funcc();
> }
> void main()
> {
>      func();
> 
> }
> ```
> So maybe the fact that `this(string y) => this(0, y);` doesn't compile is a compiler bug? Constructors return `void` after all, no?

I think so, or at least it's an undesirable special case:

```d
void foo(){ return; }
struct S{
    this(int x){ return; } // ok, can return void
    this(int x,int y){ return foo(); } // error
}
```

"Error: cannot return expression from constructor"