Menu
Search

Forums

Forum Index

December 18, 2021
Gravatar of Quirin SchrollPosted by Quirin Schroll
in reply to Igor		Reply
Quirin Schroll
Gravatar of Quirin Schroll
Posted in reply to Igor


Reply

On Friday, 17 December 2021 at 13:14:50 UTC, Igor wrote:

>

I hate language constructs that go in opposite order from my thoughts making me type something then having to navigate back to add another thing. Best example for this is casting in any language. I always have to write cast operator before the thing I am casting yet in my head I never think "then I need to cast to int the variable X that I want to add". I think more like "Then I need to add variable X but I have to cast it to int".

I feel the same about writing. But you have to consider how code is read, too. C# kind of has an infix cast operator: You write x as TargetType there. In D, you can do the same:

auto ref TargetType as(TargetType, SourceType)(auto ref SourceType object)
{
    return cast(TargetType) object;
}
auto result = fun(x.as!int).as!string;

I'll agree that an operator would look nicer, but – as is more often than not the case with D – if a library solution is found that isn't horrible, the probability that the language will be extended is around 0.

December 21, 2021
Gravatar of Steven SchveighofferPosted by Steven Schveighoffer
in reply to Quirin Schroll		Reply
Steven Schveighoffer
Gravatar of Steven Schveighoffer
Posted in reply to Quirin Schroll


Reply

On 12/18/21 2:54 PM, Quirin Schroll wrote:

>

On Monday, 15 November 2021 at 14:19:00 UTC, Steven Schveighoffer wrote:

>

On 11/15/21 7:41 AM, Timon Gehr wrote:

>

In particular, there is static foreach_reverse.

Although it's fallen mostly out of style, the reason I hated foreach_reverse is because it used to be applicable to delegate iteration, but just iterates forward (I've just checked and it's deprecated, but not disabled).

Maybe this is older. When I came to D around 2015, I learned that there is opApply for forward iteration (foreach) and opApplyReverse for reverse iteration (foreach_reverse). I just tried defining a struct with opApply, but no opApplyReverse, and then foreach_reverse on an instance (on run.dlang.io). Doesn't work.

You can foreach an appropriately typed delegate too.

e.g.

struct S
{
   int byKey(int delegate(int) dg)
   {
      return 0;
   }
}

void main()
{
   S s;
   foreach(i; &s.byKey) {}
    foreach_reverse(i; &s.byKey) {} // Deprecated, still iterates forwards
}

https://run.dlang.io/is/G3KUfl

As I said, it's fallen out of style. I used this in my dcollections library though.

-Steve

December 29, 2021
Gravatar of Era ScarecrowPosted by Era Scarecrow
in reply to Atila Neves		Reply
Era Scarecrow
Gravatar of Era Scarecrow
Posted in reply to Atila Neves


Reply

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

>
  • Worst features implemented in a non-toy language

I did some programming at a tech company in 2011, and was introduced to ASP. The default in the webpage-based language was variables were passed around using reference.

This of course turns the whole programming understanding on it's head because you assume you pass copies of native types or copy structs to the stack and you can't affect the original variables (unless you intend to or they are classes passed around).

So to get around to expected normal behavior you have to put ByVal everywhere on all arguments.

December 28, 2021
Gravatar of Walter BrightPosted by Walter Bright
in reply to Timon Gehr		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Timon Gehr


Reply
On 11/9/2021 11:09 PM, Timon Gehr wrote:
> On 10/16/21 1:12 AM, Walter Bright wrote:
>> On 10/12/2021 2:38 PM, Timon Gehr wrote:
>>> - non-lexical variable lifetimes (probably not happening)
>>
>> It's already implemented for @live.
> 
> 
> Specifically, I would like it to influence scoping.
> 
> ```d
> int x=2;
> int y=move(x);
> int z=x; // error: undefined identifier x (was moved away)

@live currently does that for pointers, but not for non-pointers. What's the use case for it?


> int y=move(y); // ok
> ```

I see what you mean, but since D disallows:

    int x; { int x; }

which prevents a number of bugs, so I can't see allowing that.
December 28, 2021
Gravatar of Walter BrightPosted by Walter Bright
in reply to Timon Gehr		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Timon Gehr


Reply
On 11/14/2021 3:05 PM, Timon Gehr wrote:
> Another issue is that it slightly expands `alias this` and I am not sure whether that's a direction Walter is willing to invest in at this point.

`alias this` suffers from being under-specified. In an attempt to fix that, I discovered it runs smack into multiple inheritance land, something I've tried to avoid. Worse, its implementation does a half-baked job of multiple inheritance, and backwards compatibility interferes with fixing it.

To move forward with it, it would have to be abandoned in its current form and completely redesigned.
December 28, 2021
Gravatar of Walter BrightPosted by Walter Bright
in reply to Timon Gehr		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Timon Gehr


Reply
On 11/15/2021 6:14 PM, Timon Gehr wrote:
> Some reassurance that it won't be shot down for stupid reasons would go a long way. For `static foreach`, the desired semantics were clear to Walter and Andrei from the start and they really wanted that feature in DMD, so that the DIP process went pretty smoothly. I am not feeling any similar excitement for tuples, even though it's the most wanted feature among forum readers according to the state of D 2018 survey... I just don't have the time and energy required for week-long forum debates anymore.

Actually, I agree with the need for tuples, and am very open to a good design for it.
December 29, 2021
Gravatar of 12345swordyPosted by 12345swordy
in reply to Walter Bright		Reply
12345swordy
Gravatar of 12345swordy
Posted in reply to Walter Bright


Reply
On Wednesday, 29 December 2021 at 05:13:55 UTC, Walter Bright wrote:

> To move forward with it, it would have to be abandoned in its current form and completely redesigned.

I am in strong favor of being replaced rather than redesigned. The only thing that is preventing alias this from being replaced entirely is implicit conversions, which incidentally is a common use of alias this.

D can do implicit conversions differently than C++, as there are other languages out there that have implicit conversions that is (IMO at least) sane and reasonable.

The question is Walter: Are you willing to bite the bullet on this or you rather look for some alternative solution here?

-Alex
December 29, 2021
Gravatar of TejasPosted by Tejas
in reply to Walter Bright		Reply
Tejas
Gravatar of Tejas
Posted in reply to Walter Bright


Reply

On Wednesday, 29 December 2021 at 05:14:43 UTC, Walter Bright wrote:

>

On 11/15/2021 6:14 PM, Timon Gehr wrote:

>

Some reassurance that it won't be shot down for stupid reasons would go a long way. For static foreach, the desired semantics were clear to Walter and Andrei from the start and they really wanted that feature in DMD, so that the DIP process went pretty smoothly. I am not feeling any similar excitement for tuples, even though it's the most wanted feature among forum readers according to the state of D 2018 survey... I just don't have the time and energy required for week-long forum debates anymore.

Actually, I agree with the need for tuples, and am very open to a good design for it.

Sorry if this sounds very naive, but if we can't use the struct ABI for tuples, why don't we use the class ABI? Yeah, reference types are undesirable, but it sounds like a very viable placeholder until we think of a better implementation.

December 28, 2021
Gravatar of Walter BrightPosted by Walter Bright
in reply to Walter Bright		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Walter Bright


Reply
On 12/28/2021 9:14 PM, Walter Bright wrote:
> Actually, I agree with the need for tuples, and am very open to a good design for it.

I'd like to see something that unified arrays, structs, argument lists (for functions).
December 29, 2021
Gravatar of Petar Kirov [ZombineDev]Posted by Petar Kirov [ZombineDev]
in reply to Walter Bright		Reply
Petar Kirov [ZombineDev]
Gravatar of Petar Kirov [ZombineDev]
Posted in reply to Walter Bright


Reply
On Wednesday, 29 December 2021 at 05:09:33 UTC, Walter Bright wrote:
> On 11/9/2021 11:09 PM, Timon Gehr wrote:
>> On 10/16/21 1:12 AM, Walter Bright wrote:
>>> On 10/12/2021 2:38 PM, Timon Gehr wrote:
>>>> - non-lexical variable lifetimes (probably not happening)
>>>
>>> It's already implemented for @live.
>> 
>> 
>> Specifically, I would like it to influence scoping.
>> 
>> ```d
>> int x=2;
>> int y=move(x);
>> int z=x; // error: undefined identifier x (was moved away)
>
> @live currently does that for pointers, but not for non-pointers. What's the use case for it?
>

The typestate [1] design pattern. In languages that support some form of affine types [2] like Rust (*), this design pattern can be used to prevent classes of programmer errors at compile-time, while the best C++ and D can do is use `assert` at run-time to facilitate detecting them. Here's a few articles that showcase this in Rust:

* https://cliffle.com/blog/rust-typestate/
* https://rustype.github.io/notes/notes/rust-typestate-series/rust-typestate-part-1
* https://docs.rs/typestate/latest/typestate/

(*) Technically, affine types are about using a variable at most once. In Rust, if a type doesn't implement the Copy / Clone traits [3], variables of that type have move semantics - that is, they can't be used after they have been passed to a function that takes them by value (passing ownership). But they can be still passed multiple times to functions take them by reference (borrowing).

[1]: https://en.wikipedia.org/wiki/Typestate_analysis
[2]: https://en.wikipedia.org/wiki/Substructural_type_system
[3]: https://doc.rust-lang.org/std/marker/trait.Copy.html
« First   ‹ Prev
… 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
Next ›   Last »