Eğer boş ise, neden modern diller onu uygular? [kapalı]

Java veya C # gibi dil tasarımcılarının boş referansların varlığına ilişkin sorunları bildiğinden eminim (bkz. Boş referanslar gerçekten kötü bir şey mi? ). Ayrıca bir seçenek türü uygulamak, boş başvurulardan çok daha karmaşık değildir.

Neden yine de dahil etmeye karar verdiler? Boş referansların bulunmamasının hem dil yaratıcılarından hem de kullanıcılardan daha kaliteli kodları (özellikle daha iyi kütüphane tasarımı) teşvik edeceği (hatta zorlayacak) eminim.

Basitçe muhafazakarlık yüzünden mi - "diğer dillerde var, bizde de olmalı ..."?

Yasal Uyarı: Herhangi bir dil tasarımcısını şahsen tanımadığım için size verdiğim cevap spekülatif olacaktır.

Gönderen Tony Hoare kendisi:

Milyar dolarlık hatam diyorum. 1965'teki boş referansın icadıydı. O zamanlar, nesne yönelimli bir dilde (ALGOL W) referanslar için ilk kapsamlı tip sistemi tasarlıyordum. Amacım, derleyici tarafından otomatik olarak yapılan kontrollerle, referansların tüm kullanımının kesinlikle güvenli olmasını sağlamaktı. Fakat boş bir referansta bulunma eğilimine karşı koyamadım, çünkü uygulanması çok kolaydı. Bu, son kırk yılda muhtemelen bir milyar dolarlık acı ve hasara neden olan sayısız hata, güvenlik açığı ve sistem çökmesine neden oldu.

Vurgu madeni.

Doğal olarak o zaman ona kötü bir fikir gibi gelmedi. O bu aynı nedenle kısmen koruyan oldu olasıdır - bu hızlı sıralama Turing ödüllü mucidi iyi bir fikir gibi görünüyordu, eğer birçok kişi şaşırtıcı değil hala o kötülük neden anlamıyorum. Kısmen de muhtemeldir, çünkü yeni dillerin hem pazarlama hem de öğrenme eğrisi nedenleriyle eski dillere benzemesi uygundur. Konuşma konusu olan mesele:

“C ++ programcılarının peşindeydik. Yarısından çoğunu Lisp'a sürüklemeyi başardık.” -Guy Steele, Java filminin ortak yazarı

(Kaynak: http://www.paulgraham.com/icad.html )

Ve tabii ki, C ++ 'ın boş değeri var çünkü C' nin değeri boş ve C'nin tarihsel etkisine girmeye gerek yok. C #, Microsoft'un Java uygulaması olan J ++ 'yı değiştirdi ve aynı zamanda C ++' ı Windows geliştirme için tercih edilen dil olarak değiştirdi, bu yüzden her ikisinden de alabilirdi.

EDIT İşte, Hoare'den göz önünde bulundurmaya değer bir başka alıntı:

Genel olarak programlama dilleri eskisinden çok daha karmaşıktır: nesne yönelimi, kalıtım ve diğer özellikler hala tutarlı ve bilimsel olarak iyi temellenmiş bir disiplin veya doğruluk teorisi açısından düşünülmemektedir. . Hayatım boyunca bir bilim insanı olarak takip ettiğim orijinal önermem, bir doğruluk ölçütünü, kullanıcılarına tuzak koymayan, iyi bir programlama dili tasarımına yakınlaşmanın bir aracı olarak kullanmaktır. programın farklı bileşenlerinin açıkça spesifikasyonunun farklı bileşenlerine karşılık geldiği için, bileşimle ilgili olarak bu konuda bir neden olabilirsiniz. [...] Derleyici de dahil olmak üzere araçlar doğru bir program yazmanın ne demek olduğuna dair bazı teorilere dayanmak zorundadır. - Philip L. Frana, 17 Temmuz 2002, Cambridge, İngiltere; Charles Babbage Enstitüsü, Minnesota Üniversitesi. [ Http://www.cbi.umn.edu/oh/display.phtml?id=343]

Yine, benimkine vurgu yap. Sun / Oracle ve Microsoft, şirketlerdir ve herhangi bir şirketin özü paradır. Kendilerine kazandırmanın yararları null, eksilere ağır basmış olabilir veya konuyu tam olarak düşünmek için çok sıkı bir son tarih almış olabilirler. Muhtemelen son teslim tarihleri ​​nedeniyle meydana gelen farklı bir dil farkına bir örnek olarak:

Cloneable'ın kırılması utanç verici bir şey, ama oluyor. Orijinal Java API'leri, kapanış pazar penceresini karşılamak için sıkı bir süre içerisinde çok hızlı bir şekilde yapıldı. Orijinal Java ekibi inanılmaz bir iş çıkardı, ancak API'lerin tümü mükemmel değil. Klonlanabilir, zayıf bir nokta ve insanların sınırlarının farkında olmaları gerektiğini düşünüyorum. -Josh Bloch

(Kaynak: http://www.artima.com/intv/bloch13.html )

Java veya C # gibi dil tasarımcılarının boş referansların varlığına ilişkin sorunları bildiğinden eminim

Tabii ki.

Ayrıca bir seçenek türü uygulamak boş referanslardan çok daha karmaşık değildir.

Naçizane size katılmıyorum! C # 2'deki null değerine giren tasarım konuları karmaşık, tartışmalı ve zordu. Hem dillerin hem de çalışma zamanlarının tasarım ekiplerini aylarca süren tartışmalara, prototiplerin uygulanmasına, vb. Götürdüler ve gerçekte açılabilir boks anlamını aslında çok tartışmalı olan C # 2.0'a çok yakın bir şekilde değiştirdiler.

Neden yine de dahil etmeye karar verdiler?

Tüm tasarım, incelikli ve kaba bir şekilde uyumsuz hedefler arasından seçim yapma sürecidir; Göz önünde bulundurulması gereken faktörlerden yalnızca birkaçı taslağını verebilirim:

• Dil özelliklerinin dikliği genellikle iyi bir şey olarak kabul edilir. C #, null değer türlerine, null olmayan değer türlerine ve null referans değerlerine sahiptir. Null olmayan referans türleri mevcut değildir, bu da tip sistemini ortogonal yapar.

• Mevcut C, C ++ ve Java kullanıcılarına aşinalık önemlidir.

• COM ile birlikte çalışabilirlik önemlidir.

• Diğer tüm .NET dilleriyle birlikte çalışabilirlik önemlidir.

• Veritabanlarıyla kolay birlikte çalışabilirlik önemlidir.

• Anlambilimin tutarlılığı önemlidir; TheKingOfFrance 'in null' a eşit olması durumunda, her zaman "şu anda Fransa Kralı yok" anlamına mı geliyor, ya da "Kesinlikle bir Fransa Kralı var; şu an kim olduğunu bilmiyorum" anlamına mı geliyor? ya da "Fransa’da bir Krala sahip olma kavramı saçma, bu yüzden soruyu sorma!" anlamına mı geliyor? Null, tüm bunları ve daha fazlasını C # ile ifade edebilir ve tüm bu kavramlar faydalıdır.

• Performans maliyeti önemlidir.

• Statik analize yatkın olmak önemlidir.

• Tip sisteminin tutarlılığı önemlidir; Null olmayan bir referansın hiçbir zaman geçersiz olduğu gözlemlenen koşullar altında olmadığını her zaman bilebilir miyiz ? NULL olmayan bir referans türü olan bir nesnenin yapıcısına ne demeli? Peki ya referansı doldurması gereken kod bir istisna attığı için böyle bir nesnenin sonlandırıcısında, nesnenin sonlandırıldığı yerde ? Garantileri konusunda size yalan söyleyen bir tip sistem tehlikelidir.

• Peki ya anlambilimin tutarlılığı? Boş değerler kullanıldığında yayılır, ancak boş referanslar kullanıldığında istisnalar atar. Bu tutarsız; Bu tutarsızlık bir fayda ile haklı mı?

• Bu özelliği diğer özellikleri bozmadan da uygulayabilir miyiz? Bu özellik gelecekteki başka hangi olası özellikleri engelliyor?

• Sahip olduğun ordu ile savaşa girersin, istediğin kişiyle değil. Unutmayın, C # 1.0 jeneriklere sahip değildi, bu yüzden Maybe<T>alternatif olarak konuşmak tamamen marşsız bir şey. Çalışma zamanı ekibi yalnızca boş başvuruları kaldırmak için jenerik ürün eklerken, .NET iki yıl boyunca kaymalı mıydı?

• Tip sisteminin tutarlılığı ne durumda? Nullable<T>Herhangi bir değer türü için söyleyebilirsiniz - hayır, bekleyin, bu bir yalan. Söyleyemezsin Nullable<Nullable<T>>. Yapabilmelisin mi? Eğer öyleyse, istenen anlambilim nedir? Tüm bu tip sistemin sadece bu özellik için özel bir durumu var mıdır?

Ve bunun gibi. Bu kararlar karmaşık.

Null, değer eksikliğini temsil etmek için çok geçerli bir amaca hizmet eder.

Özellikle liberal olarak kullanıldığında, null suistimalleri ve baş ağrıları ve neden olabilecek acıları hakkında bildiğim en vokal insanım diyeceğim.

Benim kişisel duruşum, insanların sadece gerekli ve uygun olduğunu haklı çıkarabilecekleri zaman null kullanabilmeleridir .

Null'leri yasaklama örneği:

Ölüm Tarihi, tipik olarak nULL olabilecek bir alandır. Ölüm tarihi olan üç olası durum vardır. Ya kişi öldü, tarih belli, kişi öldü ve tarih bilinmiyor, ya da kişi ölmedi ve bu nedenle ölüm tarihi yoktur.

Ölüm Tarihi ayrıca bir DateTime alanıdır ve "bilinmeyen" veya "boş" bir değere sahip değildir. Kullanılan dile bağlı olarak değişen yeni bir tarih-saat oluşturduğunuzda çıkacak varsayılan tarihe sahip olmakla birlikte, teknik olarak o kişinin ölmesi ve teknik olarak “boş değeriniz” olarak işaretlenmesi gibi bir olasılık var. varsayılan tarihi kullanın.

Verilerin durumu doğru bir şekilde göstermesi gerekir.

Ölü kişinin ölüm tarihi olduğu biliniyor (3/9/1984)

Basit, '3/9/1984'

Kişi öldü ölüm tarihi bilinmiyor

Peki en iyisi nedir? Boş , '0/0/0000' veya '01 / 01/1869 '(veya varsayılan değeriniz nedir?)

Kişi ölü değil ölüm tarihi geçerli değildir

Peki en iyisi nedir? Boş , '0/0/0000' veya '01 / 01/1869 '(veya varsayılan değeriniz nedir?)

Öyleyse her değeri düşünelim ...

• Boş , dikkatli olmanız gereken bazı sonuçları ve endişeleri var, örneğin ilk önce boş olmadığını onaylamadan kazara manipüle etmeye çalışmak, örneğin bir istisna atar, ancak aynı zamanda en iyi durumu gösterir ... Kişi ölmezse ölüm tarihi yok ... hiçbir şey ... boş ...
• 0/0/0000 , Bu, bazı dillerde tamam olabilir ve tarihin uygun bir gösterimi bile olabilir. Ne yazık ki, bazı diller ve validasyon bunu geçersiz bir tarih olarak reddeder, bu da çoğu zaman işe yaramaz hale getirir.
• 1/1/1869 (veya varsayılan datetime değeriniz ne olursa olsun) , buradaki sorun işlenmesi zorlaşır . Bunu, değer eksikliğiniz olarak kullanabilirsiniz, tüm kayıtlarımı filtrelemek istersem, ölüm tarihim olmadığı için ne olur? Veri bütünlüğü sorunlarına neden olabilecek o tarihte ölen insanları kolayca filtreleyebiliyordum.

Aslında bazen edilir Do şey temsil etmek ve emin bazen değişken türü bunun için iyi çalışır, ama çoğu zaman değişken türlerinin hiçbir şey temsil etmek gerekiyor gerekir.

Elmaları yoksa 0 elmaları var, ama ne kadar elmaları olduğunu bilmiyorsam?

Elbette, null kötüye kullanılır ve potansiyel olarak tehlikelidir, ancak zaman zaman gereklidir. Bu sadece birçok durumda varsayılandır, çünkü ben bir değer verene kadar bir değerin olmaması ve bir şeyin onu temsil etmesi gerekir. (Boş)

"Diğer dillerde var, bizde de olmalı ..." kadar Joneses'e ayak uydurmuş gibi gitmeyecektim. Herhangi bir yeni dilin en önemli özelliği, diğer dillerde mevcut kütüphanelerle birlikte çalışabilmesidir (okuma: C). C boş işaretçilere sahip olduğundan, birlikte çalışabilirlik katmanı mutlaka boş (veya kullandığınızda patlayan "başka bir" yok "eşdeğeri) kavramına ihtiyaç duyar.

Dil tasarımcısı Seçenek Türlerini kullanmayı seçebilir ve sizi null yolundaki her şeyi null yolunu kullanmaya zorlayabilirdi . Ve bu neredeyse kesinlikle daha az hataya yol açacaktır.

Ancak (özellikle Java ve C # için giriş zamanlamaları ve hedef kitleleri nedeniyle) bu birlikte çalışabilirlik katmanı için seçenek türleri kullanmak, benimsemelerine torpil vermediyse büyük olasılıkla zarar görecektir. Seçenek türü tamamen geçilir, orta ila 90'ların sonundaki C ++ programcılarının canını sıkıcı - veya birlikte çalışabilirlik katmanı, sıfırlarla karşılaşırken istisnalar atar, orta ila 90'ların sonundaki sıkıntıları C ++ programcılarından rahatsız eder. ..

Her şeyden önce, bir sıfırlık kavramının gerekli olduğu konusunda hepimizin hemfikir olabileceğini düşünüyorum . Bilginin yokluğunu göstermemiz gereken bazı durumlar var .

nullReferanslara (ve işaretçilere) izin vermek bu kavramın yalnızca bir uygulamasıdır ve sorunların bilindiği bilinmesine rağmen muhtemelen en popüler olanıdır: C, Java, Python, Ruby, PHP, JavaScript, ... hepsi benzerini kullanır null.

Neden ? Peki alternatif nedir?

Haskell gibi işlevsel dillerde siz Optionveya Maybetürünüz; ancak bunlar üzerine inşa edilmiştir:

• parametrik tipler
• cebirsel veri tipleri

Şimdi, orijinal C, Java, Python, Ruby veya PHP bu özelliklerden herhangi birini destekliyor mu? Hayır. Java'nın kusurlu jenerik dili dilin tarihinde son zamanlarda yer almaktadır ve bir şekilde diğerlerinin de onları uyguladığından şüpheliyim.

İşte aldın. nullkolaydır, parametrik cebirsel veri tipleri daha zordur. İnsanlar en basit alternatife gitti.

Boş / nil / hiçbiri kötü değildir.

Yanıltıcı olarak bilinen ünlü konuşmacısı "The Billion dollar Mistake" i izlerseniz, Tony Hoare herhangi bir değişkenin null alabilmesinin nasıl sağlanabileceğinin büyük bir hata olduğunu söyler. Alternatif - Seçeneklerini kullanarak - yok değil aslında boş referanslar kurtulmak. Bunun yerine, hangi değişkenlerin boş bırakılmasına izin verildiğini ve hangilerinin izin vermediğini belirlemenizi sağlar.

Nitekim, uygun istisna işlemeyi uygulayan modern dillerle, boş değer dereference hataları, diğer istisnalardan farklı değildir; Boş referanslara bazı alternatifler (örneğin, Null Object pattern) hataları gizler ve olayların daha sonraları sessizce başarısız olmasına neden olur. Bence hızlı başarısız olmak çok daha iyi .

Öyleyse soru şu ki, neden diller Seçenekler'i uygulayamıyor? Nitekim, tüm zamanların tartışmasız en popüler dili olan C ++, atanamayan nesne değişkenlerini tanımlama yeteneğine sahiptir NULL. Bu, Tony Hoare konuşmasında bahsettiği "boş sorun" için bir çözüm. Neden bir sonraki en popüler yazılı dil olan Java'da yok? Birileri , özellikle kendi tip sisteminde, neden bu kadar çok kusuru olduğunu sorabilir . Dillerin sistematik olarak bu hatayı yaptığını söyleyebileceğinizi sanmıyorum. Bazıları yapar, bazıları yapmaz.

Çünkü programlama dilleri teknik olarak doğru olmaktan ziyade pratik olarak yararlı olacak şekilde tasarlanmıştır. Gerçek şu ki, nulldevletler ya kötü ya da eksik veriler ya da henüz kararlaştırılmamış bir durumdan dolayı ortak bir durumdur. Teknik olarak üstün çözümler tamamen boş durumlara izin vermek ve programcıların hata yapmaları gerçeğini emmekten ziyade hantaldır.

Örneğin, bir dosyayla çalışan basit bir komut dosyası yazmak istersem şöyle bir sözde kod yazabilirim:

file = openfile("joebloggs.txt")

for line in file
{
  print(line)
}

joebloggs.txt yoksa ve basitçe başarısız olacaktır. Sorun şu ki, muhtemelen basit olan komut dosyaları için ve daha karmaşık koddaki birçok durum için bunun var olduğunu ve başarısızlık olmayacağını biliyorum, bu yüzden beni zamanımı boşa harcamayı kontrol etmeye zorluyor. Daha güvenli alternatifler, beni potansiyel başarısızlık durumuyla doğru bir şekilde başa çıkmaya zorlayarak güvenliğine kavuşurlar, ancak çoğu zaman bunu yapmak istemiyorum, sadece devam etmek istiyorum.

Orada net ve pratik kullanımları vardır NULL(ya nilya Nilya nullya Nothingya da her ne tercih ettiğiniz dil denir) pointer.

Bir istisna sistemine sahip olmayan diller için (örn. C), bir işaretçinin döndürülmesi gerektiğinde boş bir işaretçi bir hata işareti olarak kullanılabilir. Örneğin:

char *buf = malloc(20);
if (!buf)
{
    perror("memory allocation failed");
    exit(1);
}

Burada bir NULLgeri dönüş malloc(3)başarısızlık işareti olarak kullanılır.

Method / function argümanlarında kullanıldığında, argüman için varsayılan kullanım olduğunu gösterebilir veya çıktı argümanını yok sayar. Aşağıdaki örnek

İstisna mekanizmasına sahip diller için bile, boş bir işaretçi, özellikle istisna işlemesi pahalı olduğunda (örneğin Objective-C) yumuşak hatanın (yani kurtarılabilir hataların) göstergesi olarak kullanılabilir.

NSError *err = nil;
NSString *content = [NSString stringWithContentsOfURL:sourceFile
                                         usedEncoding:NULL // This output is ignored
                                                error:&err];
if (!content) // If the object is null, we have a soft error to recover from
{
    fprintf(stderr, "error: %s\n", [[err localizedDescription] UTF8String]);
    if (!error) // Check if the parent method ignored the error argument
        *error = err;
    return nil; // Go back to parent layer, with another soft error.
}

Burada yumuşak hata, yakalanmadığı takdirde programın çökmesine neden olmaz. Bu, Java gibi çılgınca denemeyi ortadan kaldırır ve yumuşak hatalar kesintiye uğramadığı için program akışında daha iyi bir kontrole sahiptir (ve geriye kalan birkaç istisna hariç, genellikle kurtarılamaz ve yakalanamaz)

İki ilgili, ancak biraz farklı konular var:

1. Hiç olmalı mı null? Yoksa Maybe<T>null yararlı olduğunda her zaman kullanmalı mıyım?

2. Tüm referanslar geçersiz sayılabilir mi? Değilse, hangisi varsayılan olmalıdır?

   Açıkça belirtilebilecek referans türlerini açıkça string?veya benzer olarak bildirmek null, programlayıcıların alıştığından çok farklı olmadan , sorunların çoğundan (ancak hepsinden değil) kaçınacaktır .

En azından tüm referansların geçersiz sayılmaması gerektiği konusunda hemfikirim. Ancak sıfırdan kaçınmak, karmaşıklığı olmadan değildir:

.NET, tüm alanları default<T>önce yönetilen kodla erişilmeden önce başlatır . Bunun anlamı, referans türleri için ihtiyacınız olan nullveya eşdeğer bir şey olduğu ve değer türlerinin kod çalıştırmadan bir tür sıfıra başlatılabileceği anlamına gelir . Bunların her ikisinin de ciddi olumsuz yönleri olsa da, defaultbaşlatmanın basitliği bu olumsuz yönlerden ağır basmış olabilir.

• Örneğin alanlar , thisişaretçiyi yönetilen koda göstermeden önce alanların başlatılmasını gerektirerek bunun üzerinde çalışabilirsiniz . Spec # bu rotaya, C # ile karşılaştırıldığında yapıcı zincirlemesinden farklı sözdizimi kullanarak gitti.

• İçin statik alanlar size basitçe gizleyemezsiniz beri tarla başlatıcısı yayınlanabilir kodun ne tür güçlü kısıtlamalar poz sürece bu sağlanması zordur thisişaretçi.

• Referans türlerinin dizileri nasıl başlatılır? Uzunluktan List<T>daha büyük kapasiteli bir dizi tarafından desteklenen bir tane düşünün . Kalan elemanların bir değere sahip olması gerekir .

Başka bir sorun da benzeri yöntemler izin olmamasıdır bool TryGetValue<T>(key, out T value)dönmek default(T)olarak valuehiçbir şey bulamazlarsa. Bu durumda, out parametresinin her şeyden önce tasarımın kötü olduğunu iddia etmek kolaydır ve bu yöntemin ayrımcı bir birliktelik veya belki de yerine geri dönmesi gerekir .

Bu sorunların tümü çözülebilir, ancak "boş ve her şey yolunda yasaklama" kadar kolay değil.

Çoğu yararlı programlama dili, veri öğelerinin rasgele diziler halinde yazılmasına ve okunmasına izin verir; böylece bir program çalıştırılmadan önce okuma ve yazma sırasını statik olarak belirlemek genellikle mümkün olmaz. Kodun aslında okumadan önce her yuvaya faydalı veri depolayacağı ancak bunun zor olacağını kanıtlayacağı birçok durum vardır. Bu nedenle, kodun henüz faydalı bir değere sahip olmayan bir şeyi okumaya teşebbüs etmek için en azından teorik olarak mümkün olduğu programları çalıştırmak çoğu zaman gerekli olacaktır. Kodun böyle yapmasının yasal olup olmadığı, kodun denenmesini engellemenin genel bir yolu yoktur. Tek soru, bu olduğunda ne olması gerektiğidir.

Farklı diller ve sistemler farklı yaklaşımlar kullanır.

• Bir yaklaşım, yazılı olmayan bir şeyi okuma girişiminin acil bir hatayı tetikleyeceğini söylemek olacaktır.

• İkinci bir yaklaşım, saklanan değerin semantik olarak yararlı olması için bir yol olmasa bile, okunması mümkün olmadan önce her yerde bir miktar değer sağlamak için kod gerektirmektir.

• Üçüncü bir yaklaşım, problemi basitçe görmezden gelmek ve “doğal olarak” ne olursa olsun gerçekleşmesine izin vermektir.

• Dördüncü bir yaklaşım, her türün varsayılan bir değere sahip olması gerektiğini ve başka bir şeyle yazılmayan herhangi bir yuvanın bu değere varsayılan olacağını söylemektir.

Yaklaşım # 4, yaklaşım # 3'ten çok daha güvenlidir ve genel olarak yaklaşım # 1 ve # 2'den daha ucuzdur. Bu daha sonra bir referans tipi için varsayılan değerin ne olması gerektiği sorusunu bırakıyor. Değişmez referans türleri için, çoğu durumda bir varsayılan örneği tanımlamak mantıklı olacaktır ve bu türdeki herhangi bir değişken için varsayılanın bu örneğe referans olması gerektiğini söyleyecektir. Değişken referans türleri için, bu çok yardımcı olmaz. Yazılmadan önce değişken bir referans türünü kullanmaya teşebbüs edilirse, genellikle kullanım girişimi tuzağından başka bir güvenli işlem yapılmaz.

Tek bir dizi varsa semantik, konuşma customersÇeşidi Customer[20]ve bir girişimleri Customer[4].GiveMoney(23)için saklanan bir şey kalmadan Customer[4], yürütme tuzağına sahip oluyor. Bir kişi, okuma girişiminin Customer[4], kod denemeye kadar beklemek yerine derhal tuzağa düşmesi gerektiğini savunabilir GiveMoney, ancak bir slotu okumak, bir değeri tutmadığını anlamak ve bundan faydalanmak için yeterli durumlar vardır. okuma girişiminin başarısız olmasının genellikle büyük bir sıkıntı olacağı bilgisi.

Bazı diller, birinin belirli değişkenlerin hiçbir zaman boş bırakmaması gerektiğini ve boş bir saklama girişiminde hemen bir tuzak tetiklemesi gerektiğini belirtir. Bu yararlı bir özellik. Bununla birlikte, genel olarak, programcıların referans dizileri oluşturmasına izin veren herhangi bir dilin, ya boş dizi elemanlarının olasılığına izin vermesi gerekecek ya da dizi elemanlarının başlatılmasını, muhtemelen anlamlı olamayacak olan verilere zorlaması gerekecektir.