Menu
Search

Forums

Forum Index

February 04, 2022
Gravatar of Basile B.Posted by Basile B.
in reply to Tejas		Reply
Basile B.
Gravatar of Basile B.
Posted in reply to Tejas


Reply

On Friday, 4 February 2022 at 17:18:54 UTC, Tejas wrote:

>

So maybe the fact that this(string y) => this(0, y); doesn't compile is a compiler bug? Constructors return void after all, no?

No, aggregate ctors are not void but the return is generated by the compiler.

February 04, 2022
Gravatar of Timon GehrPosted by Timon Gehr
in reply to Basile B.		Reply
Timon Gehr
Gravatar of Timon Gehr
Posted in reply to Basile B.


Reply
On 04.02.22 19:03, Basile B. wrote:
> On Friday, 4 February 2022 at 17:18:54 UTC, Tejas wrote:
>> So maybe the fact that `this(string y) => this(0, y);` doesn't compile is a compiler bug? Constructors return `void` after all, no?
> 
> No, aggregate ctors are not `void` but the return is generated [by the compiler](https://github.com/dlang/dmd/blob/51882e40fd17ed4b57a8ce3a355ea76b55d777c9/src/dmd/semantic3.d#L771-L780). 
> 
> 

That's an implementation/ABI detail. Plain "return" is allowed, just as if the constructor returned `void`.

https://github.com/dlang/dmd/blob/51882e40fd17ed4b57a8ce3a355ea76b55d777c9/src/dmd/statementsem.d#L2849-L2852

Therefore, it makes sense to do this rewrite in constructors too:
https://github.com/dlang/dmd/blob/51882e40fd17ed4b57a8ce3a355ea76b55d777c9/src/dmd/statementsem.d#L2896-L2910
February 04, 2022
Gravatar of Ola Fosheim GrøstadPosted by Ola Fosheim Grøstad
in reply to Tejas		Reply
Ola Fosheim Grøstad
Gravatar of Ola Fosheim Grøstad
Posted in reply to Tejas


Reply

On Friday, 4 February 2022 at 17:18:54 UTC, Tejas wrote:

>

Actually, the following compiles:

void funcc()
{
}

void func()
{
    return funcc();
}
void main()
{
    func();

}

That syntax sucks. void isn't constructible. It only makes sense if you also allow return void();

February 04, 2022
Gravatar of Paul BackusPosted by Paul Backus
in reply to Timon Gehr		Reply
Paul Backus
Gravatar of Paul Backus
Posted in reply to Timon Gehr


Reply
On Friday, 4 February 2022 at 17:59:40 UTC, Timon Gehr wrote:
> On 04.02.22 18:18, Tejas wrote:
>> On Friday, 4 February 2022 at 14:46:39 UTC, Paul Backus wrote:
>>>     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?)

It's not super common, but it does show up. Some examples:

https://github.com/dlang/phobos/blob/v2.098.1/std/algorithm/setops.d#L901
https://github.com/dlang/phobos/blob/v2.098.1/std/algorithm/iteration.d#L2051-L2052
https://github.com/dlang/phobos/blob/v2.098.1/std/encoding.d#L487-L549
https://github.com/dlang/phobos/blob/v2.098.1/std/datetime/systime.d#L9564-L9574
https://github.com/dlang/phobos/blob/v2.098.1/std/math/exponential.d#L2748-L2755
https://github.com/dlang/phobos/blob/v2.098.1/std/experimental/allocator/building_blocks/stats_collector.d#L199-L200
February 05, 2022
Gravatar of baussPosted by bauss
in reply to Mike Parker		Reply
bauss
Gravatar of bauss
Posted in reply to Mike Parker


Reply

On Friday, 4 February 2022 at 10:53:45 UTC, Mike Parker wrote:

>

Discussion Thread

This is the discussion thread for the first round of Community
Review of DIP 1043, "Shortened Method Syntax":

https://github.com/dlang/DIPs/blob/5a3b437f2b6be8fb23e855fc0da20f19f68edac8/DIPs/DIP1043.md

The review period will end at 11:59 PM ET on February 18, or
when I make a post declaring it complete. Discussion in this
thread may continue beyond that point.

Here in the discussion thread, you are free to discuss anything
and everything related to the DIP. Express your support or
opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the
proposal itself, then please post it in the Feedback Thread. The
Feedback Thread will be the source for the review summary that I
will write at the end of this review round. I will post a link to
that thread immediately following this post. Just be sure to read
and understand the Reviewer Guidelines before posting there:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

And my blog post on the difference between the Discussion and
Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are completely off-topic.

From the DIP itself it wasn't clear to me whether it would only support expressions that returns a value or not, because to me it should also support expressions that don't necessarily yield a value.

So both these would be valid:

void foo() { ... }
void bar() => foo(); // This

private int _value;
void baz(int value) => _value = value; // And this
int baz() => _value;

If it's supported then I'm all for this, but if not then I think it's only a half-baked implementation.

February 04, 2022
Gravatar of Steven SchveighofferPosted by Steven Schveighoffer
in reply to bauss		Reply
Steven Schveighoffer
Gravatar of Steven Schveighoffer
Posted in reply to bauss


Reply

On 2/4/22 7:17 PM, bauss wrote:

>

On Friday, 4 February 2022 at 10:53:45 UTC, Mike Parker wrote:

>

Discussion Thread

This is the discussion thread for the first round of Community
Review of DIP 1043, "Shortened Method Syntax":

https://github.com/dlang/DIPs/blob/5a3b437f2b6be8fb23e855fc0da20f19f68edac8/DIPs/DIP1043.md

The review period will end at 11:59 PM ET on February 18, or
when I make a post declaring it complete. Discussion in this
thread may continue beyond that point.

Here in the discussion thread, you are free to discuss anything
and everything related to the DIP. Express your support or
opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the
proposal itself, then please post it in the Feedback Thread. The
Feedback Thread will be the source for the review summary that I
will write at the end of this review round. I will post a link to
that thread immediately following this post. Just be sure to read
and understand the Reviewer Guidelines before posting there:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

And my blog post on the difference between the Discussion and
Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are completely off-topic.

From the DIP itself it wasn't clear to me whether it would only support expressions that returns a value or not, because to me it should also support expressions that don't necessarily yield a value.

So both these would be valid:

void foo() { ... }
void bar() => foo(); // This

private int _value;
void baz(int value) => _value = value; // And this
int baz() => _value;

If it's supported then I'm all for this, but if not then I think it's only a half-baked implementation.

there's a preview switch.

Looks like the second case is not supported in the current implementation.

onlineapp.d(5): Error: cannot return non-void from void function

But... a one-line void function doesn't need a return statement, so using a shortened method doesn't give much benefit.

-Steve

February 05, 2022
Gravatar of Basile B.Posted by Basile B.
in reply to bauss		Reply
Basile B.
Gravatar of Basile B.
Posted in reply to bauss


Reply

On Saturday, 5 February 2022 at 00:17:23 UTC, bauss wrote:

>

So both these would be valid:

void foo() { ... }
void bar() => foo(); // This

private int _value;
void baz(int value) => _value = value; // And this
int baz() => _value;

Second case works with a void cast:

void baz(int value) => cast(void) (_value = value);
February 05, 2022
Gravatar of forkitPosted by forkit
in reply to Mike Parker		Reply
forkit
Gravatar of forkit
Posted in reply to Mike Parker


Reply
On Friday, 4 February 2022 at 10:53:45 UTC, Mike Parker wrote:
>

I am neither for or against it really.

It is clear that the D programming language is really more 'a collection of dialects', including those whose only real value, is that they save you a few keystrokes.

That's the upside of the proposal I assume?

The downside, is the additional cognitive load.
February 05, 2022
Gravatar of Ola Fosheim GrøstadPosted by Ola Fosheim Grøstad
in reply to forkit		Reply
Ola Fosheim Grøstad
Gravatar of Ola Fosheim Grøstad
Posted in reply to forkit


Reply
On Saturday, 5 February 2022 at 08:12:32 UTC, forkit wrote:
> The downside, is the additional cognitive load.

Most likely a negative change, makes it easier to write code that looks messy.
February 05, 2022
Gravatar of Basile B.Posted by Basile B.
in reply to Timon Gehr		Reply
Basile B.
Gravatar of Basile B.
Posted in reply to Timon Gehr


Reply
On Friday, 4 February 2022 at 18:21:44 UTC, Timon Gehr wrote:
> On 04.02.22 19:03, Basile B. wrote:
>> On Friday, 4 February 2022 at 17:18:54 UTC, Tejas wrote:
>>> So maybe the fact that `this(string y) => this(0, y);` doesn't compile is a compiler bug? Constructors return `void` after all, no?
>> 
>> No, aggregate ctors are not `void` but the return is generated [by the compiler](https://github.com/dlang/dmd/blob/51882e40fd17ed4b57a8ce3a355ea76b55d777c9/src/dmd/semantic3.d#L771-L780).
>> 
>> 
>
> That's an implementation/ABI detail. Plain "return" is allowed, just as if the constructor returned `void`.
>
> https://github.com/dlang/dmd/blob/51882e40fd17ed4b57a8ce3a355ea76b55d777c9/src/dmd/statementsem.d#L2849-L2852
>
> Therefore, it makes sense to do this rewrite in constructors too:
> https://github.com/dlang/dmd/blob/51882e40fd17ed4b57a8ce3a355ea76b55d777c9/src/dmd/statementsem.d#L2896-L2910

sure, but my point was to say that Tejas assumption about void returns was wrong.

Anyway, it is not reported in the feedback thread for now. The document should mention something about ctor calls since the compiler does special things that
prevent shorthand syntax to work.
« First   ‹ Prev
1 2 3 4 5 6
Next ›   Last »