On Saturday, 26 November 2022 at 09:13:04 UTC, Ali Çehreli wrote:
> On 11/25/22 23:11, Salih Dincer wrote:
> örtük olarak dönüştürmekten (implicitly converts) kasıt ne
demektir?
cast kullanmayı gerektirmeyen değişim demek. Ben "otomatik tür dönüşümü" demişim:
http://ddili.org/ders/d/tur_donusumleri.html#ix_tur_donusumleri.otomatik%20t%C3%BCr%20d%C3%B6n%C3%BC%C5%9F%C3%BCm%C3%BC
http://ddili.org/ders/d/alias_this.html#ix_alias_this.otomatik%20t%C3%BCr%20d%C3%B6n%C3%BC%C5%9F%C3%BCm%C3%BC
Merhaba hocam, buraya dili tasarlayan büyük usta Walter'ın ifadelerini de yansıtmak gerek. Çünkü çok güzel yazmış:
On Tuesday, 17 January 2023 at 20:16:25 UTC, Walter Bright wrote:
> Implicit conversion is fine by itself. But consider the combinations of:
- inheritance
- alias this
- overloading
- implicit conversion
- multiple inheritance
- multiple alias this
- integer promotion
(which all can be considered forms of implicit conversion) and it becomes incomprehensible.
It's not a question of "can we come up with a set of rules to make it all work". We certainly can. Whether the rules are predictable and intuitive rather than arbitrary and capricious is another matter entirely.
Case in point - C++ overloading rules. Last time I checked, they are two rather dense pages in the C++ Standard. I don't know anyone who can keep those rules in their head. I know I can't, and I implemented them correctly.
So how do people deal with it? This is what they tell me - they try random things until it works. They don't know why it works, and don't really care, they just move on.
This was one of the things that motivated me to move away from C++. D shouldn't be another C++. The overloading rules in D are much less complicated in C++ (because D uses the "least as specialized" rule), but still more complex than I'm comfortable with.
(The "least as specialized" rule is what C++ uses for template overloading, the C++ developers found a better way than the rats' nest of function overloading rules. I thought that would work better for function overloading, and indeed it does.)
If we go down the road of C++ complexity, we can't come back from it. We'll be stuck like C++ is stuck with function overloading.
Deciding what to leave out of a language is just as important as deciding what to put in. In fact, maybe it's more important.
SDB@79