Thread overview
Örtük Dünüştürme ne demek?
November 26

Merhaba Ali hocam,

Şu sayfada şimdi vereceğim açıklamalar ile birlikte basit bir kod verilmiş...

>

Like the normal if, static if conditionally compiles a code block based on a condition that can be evaluated at compile time:

Örnek kodun içinde, is'in bir x değişkenini typeof marifetiyle kullanımından bahsediyor:

static if(is(T == int))
    writeln("T is an int");
static if (is(typeof(x) :  int))
    writeln("Variable x implicitly converts to int");

Tabii ki kodda anlaşılmayacak bir şey yok hele ki yılların if'nin başına static koymak ile derleme anında koşula göre koda dahil edelecek/edilmeyecekleri belirleyebiliyoruz.

Peki örtük olarak dönüştürmekten (implicitly converts) kasıt ne demektir?

Teşekkürler...

November 26
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

Ali

Not: Yalnızca hatırlatmak için, bu bilgi şöyle bulunabiliyor:

1) http://ddili.org/ders/d/index.html sayfasında solda "... bütün sözlük"e tıklanabilir

2) ve "implicit"in karşılığı olarak "otomatik" kullanıldığı görülebilir.

3) Ondan sonra, yine 1'deki sayfada "Kitap dizini"ne tıklanabilir ve "otomaik dönüşüm" aranabilir.

November 26
On Saturday, 26 November 2022 at 09:13:04 UTC, Ali Çehreli wrote:
> 
> 2) ve "implicit"in karşılığı olarak "otomatik" kullanıldığı görülebilir.

Aslında "automatic" de bir İngilizce, belki "dolaylı dönüşüm" diyebiliriz.

Cevap için teşekkürler...
December 01
On Saturday, 26 November 2022 at 09:56:27 UTC, Salih Dincer wrote:
> Cevap için teşekkürler...

Bu konuyu devam ettirmek istiyor gibiyim. Mesela yeni öğrendiğim bir şey geçmiş bir zamanda Walter açık bir dille işleç yüklemesine karşı olduğunu yazmış:

2020 YILI: https://forum.dlang.org/post/rs9k19$1982$1@digitalmars.com

DAHA DA ESKİ, 2004:
https://forum.dlang.org/post/cqoj59$sle$1@digitaldaemon.com

Paul ise bunun artık kaçınılmaz olabileceğinden bahsediyor:

https://forum.dlang.org/post/yejtofadjavdcsjyswbl@forum.dlang.org

Neyse, aslında geçmiş tartışmaları uzatmak da istemiyor ve konuyu şu DIP taslağına getirmek istiyorum:

https://github.com/WalterBright/DIPs/blob/sumtypes/DIPs/1NNN-(wgb).md

Belli ki bunun için ayrı bir başlık açacağız. Ali hocamın çok vakti olmadığı için bunu üstlenebilirim ama gelişmeleri onun kadar iyi takip edemem. Şahsen ben güncel veri ve haberler ile çok ilgileniyorum ama her manaya gelebilecek şu kahrolası İngilizce beni deli ediyor 😀

Pes etmek yok, güzel şeyler oluyorsa da şu SumTypes olayı çok kafa karıştırıcı.

Hocam bu konularda diyecek birkaç sözünüz olmalı?

Haa, arkadaşlar bir de EnumTypes için yeni ve bence gerekli bir DIP1044'dümüz oldu:

https://github.com/WalterBright/DIPs/blob/master/DIPs/DIP1044.md

Hoş, ihtiyaç olsa da o dolar işaretini hiç sevmedim, sevemedim ve hepsinden önemlisi D'ye hiç ama hiç yakışmıyor. Varsın with() kullansınlar. Şahsen, ihtiyaç olsa da 1044'ü desteklemiyorum.

Sevgiler, saygılar...

November 30
On 11/30/22 17:38, Salih Dincer wrote:

> geçmiş bir zamanda Walter açık bir dille işleç yüklemesine karşı
> olduğunu yazmış:

"İşleç yükleme" deyince fazla genelliyorsun. Karşı olduğu, otomatik dönüşümler.

> Neyse, aslında geçmiş tartışmaları uzatmak da istemiyor ve konuyu şu DIP
> taslağına getirmek istiyorum:
>
> https://github.com/WalterBright/DIPs/blob/sumtypes/DIPs/1NNN-(wgb).md

Çoğu modern dilde bulunan SumType olanağı D'de kütüphane yoluyla çözülmüş durumda. Walter, o bağlantıda bunun nerelerde yetersiz kaldığını "Prior Work" altında listelemiş.

> Pes etmek yok, güzel şeyler oluyorsa da şu SumTypes olayı çok kafa
> karıştırıcı.

Toplantılarımızda bir kaç kere çalışmıştık.

> Hocam bu konularda diyecek birkaç sözünüz olmalı?

Bu noktada, dile eklenmesi kaçınılmaz.

> Haa, arkadaşlar bir de EnumTypes için yeni ve bence gerekli bir
> DIP1044'dümüz oldu:
>
> https://github.com/WalterBright/DIPs/blob/master/DIPs/DIP1044.md
>
> Hoş, ihtiyaç olsa da o dolar işaretini hiç sevmedim, sevemedim ve
> hepsinden önemlisi D'ye hiç ama hiç yakışmıyor.

Kural keşke şöyle olabilseymiş:

- Bir enum yerine kullanılan ifadede enum türü belirtilmemişse sanki başına elle yazılmış gibi kabul et.

Herhalde en başta gösterdiğin otomatik dönüşüm konusuna girdiği için $'ı gerektirmişler. Yoksa yanlışlıkla yazılmış olan bir kelime gizlice derlenebilirmiş galiba. $ yazınca kendimizi bu hataya bilerek açmış olalım diye düşünmüş olmalılar.

> Varsın with()
> kullansınlar. Şahsen, ihtiyaç olsa da 1044'ü desteklemiyorum.

Hiç sorma. DIPler bazen ne kadar gereksiz oluyorlar. Herhalde tutuculuğum ortaya çıkıyor ama "olsa ne iyi olur" diye olanak mı eklenir. Elle tutulur bir sorun mu varmış? Bence yokmuş.

Ali

January 18

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:

  1. inheritance
  2. alias this
  3. overloading
  4. implicit conversion
  5. multiple inheritance
  6. multiple alias this
  7. 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