RFC itu memiliki 4 fitur berbeda, namun kami masih hanya memiliki satu masalah pelacakan untuk semuanya. Bisakah kita tidak mendorong fitur bersama-sama berbeda seperti ini?

@retep998 Seperti yang dijelaskan di seluruh diskusi RFC, fitur-fitur ini terhubung melalui pertimbangan desain global. Misalnya, menyediakan mekanisme eksternal untuk mengganti nama peti sebagian dimotivasi oleh penghentian extern crate . Kami dapat dan akan membuka gerbang berbagai aspek secara terpisah (dan kemungkinan akan memiliki beberapa gerbang yang tumpang tindih untuk mencoba sintaks yang berbeda), tetapi untuk diskusi tentang desain dan stabilisasi keseluruhan, penting untuk mengingat koherensi global.

Memiliki mekanisme eksternal untuk mengganti nama peti adalah sesuatu yang telah diinginkan dan dibutuhkan selama bertahun-tahun (https://github.com/rust-lang/cargo/issues/1311) dan bisa saja berdiri sendiri dengan baik, tetapi malah digunakan sebagai tidak lebih dari pion untuk mendukung membunuh extern crate .

Kami tidak memiliki masalah dengan memiliki RFC terpisah untuk fitur yang terkait erat di masa lalu (teringat RFC untuk repr(align(N)) dan repr(packed(N)) ), namun sekarang kami mengklaim bahwa mengubah foo/mod.rs ke foo.rs sangat erat hubungannya dengan extern:: dan crate:: sehingga mereka harus berada di RFC yang sama dan menggunakan masalah pelacakan yang sama?

Hanya untuk memastikan poin ini bertahan, karena ini adalah aspek yang relatif halus dari sintaks pertanyaan yang belum terselesaikan: Menggunakan crate sebagai pengubah visibilitas serta awalan jalur memperkenalkan ambiguitas penguraian antara crate ::absolute::path dan crate::relative::path . Menggunakan kata kunci kontekstual menimbulkan ambiguitas yang sama, dan tidak ada kata kunci cadangan lainnya yang benar-benar masuk akal sebagai pengubah visibilitas.

Karena itu saya ingin (setidaknya) bereksperimen dengan meninggalkan pengubah visibilitas crate dan tetap menggunakan pub(crate) .

Saya tidak keberatan membagi titik foo.rs / foo/mod.rs menjadi masalah pelacakan terpisah, karena itu benar-benar tampak tidak tergantung pada jalur dan perubahan pengubah visibilitas.

Sejauh peti penggantian nama eksternal ... sudah ada adalah masalah yang terpisah untuk itu? Ini cukup penting untuk perubahan jalur jadi saya pikir tidak apa-apa menjadi bagian dari yang satu ini juga .

Meskipun banyak diskusi beberapa minggu yang lalu mengenai pilihan crate sebagai pengubah visibilitas (bukan awalan jalur), saya kecewa melihat bahwa meskipun pilihan kata kunci ini terdaftar sebagai 'pertanyaan yang belum terselesaikan' di RFC, sekarang tampaknya telah dilupakan. Saya sendiri, dan beberapa orang lain yang saya catat, menemukan pilihan ini membingungkan karena ini bukan kata sifat/pengubah, dan juga bisa ambigu: apakah crate berarti bagian dari API publik peti? Tidak! Itu berarti local atau internal atau pub (terpasang) ke peti (karenanya saya lebih memilih kata kunci yang terakhir). Jadi saya tidak menuntut perubahan segera, tetapi setidaknya mengakuinya sebagai pertanyaan yang belum terselesaikan dalam masalah pelacakan ini, sehingga tidak dilupakan setelah stabilisasi.

Sangat bagus bahwa desain ulang modul ini telah berkembang sejauh ini, tetapi pada saat yang sama penting bahwa kita tidak melakukan kesalahan di depan hanya untuk membuat 'periode impl', dan akhirnya membuat keputusan tanpa berkonsultasi dengan mayoritas pengguna Rust. Dan, sayangnya, saya pikir orang-orang yang terlibat dalam diskusi Github RFC tidak mewakili seluruh basis pengguna, karena banyaknya informasi/komentar/pendapat di sana dapat mengecewakan. Jadi entah bagaimana itu perlu ditangani juga.

Tidak jelas bagaimana implementasinya berakhir ...

@rpjohnst @retep998 Saya telah membuka RFC baru untuk membahas foo.rs + foo/ serta mengusulkan beberapa perbaikan pada RFC ini.

Sunting: Saya sarankan kita membuka RFC lain untuk membahas crate sebagai pengubah visibilitas. Secara pribadi saya ingin melihat sebaliknya: pub(extern) ditambahkan dan diperlukan untuk semua simbol yang diterbitkan secara eksternal. Ini akan membuat pub menjadi setara dengan pub(crate) di epoch berikutnya.

@rpjohnst

memperkenalkan ambiguitas penguraian antara crate ::absolute::path dan crate::relative::path

Bukankah kode crate ::relative::path tidak valid? Tidak bisakah itu ditolak selama penguraian?

@est31 Tidak, itu membutuhkan resolusi nama selama penguraian yang jelas bukan sesuatu yang ingin kami lakukan. Ini adalah salah satu bagian yang lebih mengganggu dari penguraian C dan C++, yang memiliki ambiguitas serupa sekitar a * b menjadi perkalian atau deklarasi, dan sekitar a b(c, d); menjadi deklarasi variabel atau prototipe fungsi.

Jika kita pernah mulai mengizinkan dependensi dan modul tingkat atas dengan nama yang sama, bahkan mengatasi resolusi nama dengan parsing tidak akan menyelamatkan kita- crate :: some :: item bisa menjadi crate -terlihat item dari ketergantungan some , atau pribadi item dari modul tingkat atas some .

Untuk menjaga ini dalam perspektif, kita bisa saja secara sewenang-wenang menyelesaikan ambiguitas dengan satu atau lain cara dan meminta tanda kurung untuk menulis kasus lain (mungkin crate -visibility absolute path case, yang tampaknya paling langka), tapi itu masih sebuah foot-gun yang tidak kita perlukan jika kita tetap menggunakan pub(crate) , yang telah memecahkan ambiguitas sintaksis.

Menggunakan peti sebagai pengubah visibilitas serta awalan jalur memperkenalkan ambiguitas penguraian antara crate ::absolute::path dan crate::relative::path .

Ini adalah masalah kecil, IMO, mengingat bahwa visibilitas pada bidang struct Tuple dan jalur absolut "inline" jarang terjadi.
Jalur selalu diurai dengan rakus saat ini, jadi masuk akal jika crate :: x :: y berarti crate::x::y .
Jika makna yang berlawanan diinginkan, maka pub(crate) ::x::y atau crate (::x::y) dapat digunakan.

@rpjohnst @petrochenkov dapatkah Anda membagikan contoh kode di mana pub ::relative::path adalah kode yang valid? Saya tidak mendapatkan seluruh ambiguitas karena saya pikir salah satu dari dua kasus tidak valid.

Sunting: satu-satunya tempat di mana ini bisa menjadi relevan adalah di dalam makro saat Anda mencocokkan kualifikasi visibilitas + jalur. Tapi itu kerusakan yang sangat kecil sehingga bisa diterima IMO.

@est31 Anda tampaknya memiliki ide yang salah - ini bukan tentang jalur relatif, mereka tidak pernah menjadi masalah. Ini tentang membangun AST sebelum Anda tahu apa yang dirujuk oleh nama-nama itu. Berikut contoh lengkapnya:

struct S(crate :: x :: y);

Mengingat Anda belum diizinkan untuk mencari nama-nama itu, bagaimana Anda mengubah string karakter itu menjadi AST? Ada dua kemungkinan jawaban. Seseorang memiliki bidang pribadi dari tipe y didefinisikan dalam modul x dari peti saat ini. Yang lain memiliki bidang crate -terlihat dari jenis yang berbeda y ditentukan di tingkat atas ketergantungan x . Tidak perlu makro.

@rpjohnst saya melihat terima kasih untuk mengklarifikasi. Ini memang sebuah ambiguitas.

@rpjohnst

Solusi sederhana adalah mendefinisikannya dengan jelas mengurai ke pengubah visibilitas peti. Jika Anda ingin menguraikannya sebagai struct Tuple dengan anggota pribadi dari tipe yang diberikan, lakukan seperti ini:

    struct S(:: crate :: x :: y);

(perhatikan awalan :: untuk menunjukkan root 'namespace')

Ini konsisten dengan bagaimana ruang nama root lainnya perlu dirujuk dalam submodul (misalnya ::std::x::y ).

Hanya disambiguasi menjadi crate -as-a-visibility akan agak mengejutkan, saya pikir. Tetapi mungkin ide yang baik untuk "mengkanonikalisasi" solusi itu sedikit dan menegakkan bahwa crate:: selalu digunakan dengan :: (di luar use tentu saja). Seperti yang Anda tunjukkan, ini meningkatkan simetri dengan jalur yang mirip ::std::x::y , dan meninggalkan bentuk tanpa awalan untuk jalur yang benar-benar relatif ( self:: / super:: / something_in_scope:: ).

Haruskah kita melakukan ini? Mengizinkan crate::x::y di jalur non- use membuat crate semacam magis, sementara menerapkan ::crate::x::y cakupannya ke tingkat yang sama dengan dependensi, itulah yang kami lakukan re mencoba untuk menyiratkan pula.

@rpjohnst

menegakkan bahwa crate:: selalu digunakan dengan :: (di luar penggunaan tentu saja)

Ini mungkin masuk akal, setidaknya untuk permulaan (tidak ada yang mencegah relaksasi ini nanti).

Saya bukan penggemar sintaks use extern::bar::foo atau use crate::bar::foo . Tampaknya sangat bising. Saya lebih suka gula untuk ini. Saya menyarankan extern bar::foo untuk ini.

Bagaimana kalau menambahkan satu aturan implisit lagi? Impor peti eksternal secara otomatis ke root namespace, buat ekspresi jalur yang lebih bertepatan. (Saya tidak pandai bahasa Inggris, tolong pelajari pandangan saya dari contoh berikut)

misalnya

1. Struktur proyek kami seperti ini:

src
|--lib.rs
|--foo.rs
|--foo
|----|--bar.rs

1. Anda mengonfigurasi ketergantungan di Cargo.toml, seperti
   [dependencies] serde = "3.0.0"

2. kita tambahkan mod bar ke mod foo , dan tambahkan mod foo ke lib.rs,

3. kita mendefinisikan fungsi finlib di lib.rs, mendefinisikan fungsi finfoo di foo.rs, mendefinisikan fungsi finbar di bar.rs

Jadikan scope extern crate sebagai modul level atas di crate, maka kita bisa menulis kode seperti ini dimana saja.

untuk jalur penuh/memenuhi syarat

::serde::Deserialize
::serde::x::y
::finlib                            // not ::crate::finlib
::foo::finfoo                   // not ::crate::foo::finfoo
::foo::bar::finbar           // not ::crate::foo::bar::finbar

jalur relatif tulis seperti ini

serde::Deserialize      // no need to write `use serde`
serde::x::y                   // no need to write `use serde`
finlib                          
foo::finfoo                  
bar::finbar       

pertama-tama kita mencari serdefinlibfoo di lingkup mod saat ini, jika tidak ditemukan cari di mod makan malam, hingga namespace root. jika ada konflik nama, kami menulis path lengkap sebagai gantinya.

kita juga dapat menggunakan self::bar::finbar di foo.rs untuk menghindari pencarian nama.

Saya tidak dapat menemukan utas sebelumnya yang membahas ini, tetapi kompiler dulu bekerja seperti itu dan itu menyebabkan masalah besar untuk resolusi nama. IIRC @pcwalton atau @arielb1 mungkin lebih tahu.

Bukankah solusi termudah untuk ambiguitas ini adalah dengan menggunakan kata kunci yang berbeda untuk pengubah visibilitas peti-lokal (yaitu: penggantian pub(crate) ). Misalnya, local , seperti yang disarankan berkali-kali sebelumnya dalam diskusi RFC sebelumnya. Kemudian struct S(local :: x :: y) berbeda dari struct S(crate :: x :: y) .

Itu hanya menimbulkan ambiguitas lain antara <visibility> <absolute path> dan <relative path starting with the new keyword> , karena kata kunci new harus kontekstual.

@rpjohnst ah sial.. Tapi bukankah itu masalah yang dirancang untuk dipecahkan oleh zaman? Contoh: pada epoch saat ini kita hanya menggunakan pub(crate) , kemudian di epoch berikutnya, memperkenalkan kata kunci non-kontekstual baru yang lebih 'ergonomis'.

@ neon64 ya tetapi ini adalah klaim oleh RFC bahwa itu tidak memerlukan zaman baru. Klaim itu sepertinya tidak berlaku.

Ini berlaku baik- saat ini tidak ada kode yang menggunakan visibilitas crate atau jalur crate:: , jadi hanya kode baru yang akan terpengaruh. Selama kami memilih resolusi dan mematuhinya, tidak akan ada masalah kompatibilitas.

Satu hal yang terpikir oleh saya, dengan permintaan maaf jika telah diangkat sebelumnya dalam salah satu diskusi (saya tidak ingat pernah melihatnya di pasangan terakhir):

Dalam proposal terbaru, kami memiliki crate:: untuk merujuk ke "dalam peti ini" dan self:: untuk merujuk ke "dalam modul ini". Ini sedikit tidak konsisten dan berpotensi kurang jelas daripada yang seharusnya: untuk satu hal, di mana self merujuk ke "ini", pada dasarnya tidak jelas "ini apa ", dan sebaliknya, dari fakta bahwa ada self:: yang berarti " modul ini ", orang mungkin menyimpulkan bahwa crate:: dapat berarti " beberapa peti

Salah satu solusi yang mungkin adalah menghapus self:: demi mod:: . Kemudian kita akan memiliki crate:: berarti "dalam peti penutup terdekat", dan mod:: berarti "dalam modul penutup terdekat", dan itu akan menjadi jelas dan konsisten. Kami juga berpotensi memecahkan masalah di mana tidak mungkin untuk merujuk ke item dalam lingkup fn dengan cara yang memenuhi syarat sama sekali dengan memperkenalkan awalan fn:: , yang secara tidak terduga berarti "dalam fn terlampir terdekat trait:: atau impl:: .)

@glaebhoerl itu proposal yang menarik. Secara pribadi, saya pikir saya telah menemukan ide untuk memperkenalkan sintaks baru untuk jalur absolut dan mencela yang sudah ada. Saya tidak yakin seperti apa seharusnya sintaks ini, tetapi saya akan menjelaskan satu kemungkinan di bawah ini (yang saya tahu telah melayang sebelumnya).

Bayangkan kita memiliki tata bahasa berikut untuk jalur:

Path = AbsolutePath | RelativePath
AbsolutePath = 
    | `@` ID? 
    | `@` ID? `::` RelativePath
    | `self` :: RelativePath
    | `super` :: RelativePath
RelativePath = ID (`::` ID)*

Di bawah tata bahasa ini, seseorang akan mereferensikan hal-hal dari peti lain dengan memulai dengan @crate , misalnya:

use <strong i="13">@std</strong>::collections::HashMap;

Seseorang akan mereferensikan peti lokal hanya dengan @ , misalnya:

use @::something::in::my::crate;

(Dan use self::something tetap sama seperti hari ini, baik atau buruk.)

Sesuatu yang menyenangkan tentang ini adalah bahwa jalur absolut benar-benar membedakan dari jalur relatif, yang berarti kami sekarang memiliki properti yang diinginkan yang dapat disalin dan ditempelkan jalur dari use ke dalam kode dan berfungsi:

fn foo() {
    <strong i="24">@std</strong>::cmp::min(a, b) // OK
}

Ini tidak benar hari ini, yang pasti membingungkan saya dari waktu ke waktu.

Kami juga menghilangkan ambiguitas penguraian di sekitar crate , sehingga Anda dapat melakukan pub Foo(crate @::MyType) atau apa pun dan itu berfungsi dengan baik.

(Secara umum, memiliki jalur relatif dan absolut dimulai dengan :: telah menjadi sumber rasa sakit berkali-kali, adalah kebenarannya.)

Satu hal yang saya tidak tahu adalah apakah @foo adalah yang terbaik. Opsi lain yang menurut saya berhasil dan yang saya pikirkan adalah [] :

• [std]::collections dan [crate]::collections // []::collections sepertinya terlalu aneh.

Saya benar-benar tidak berpikir kita harus memperkenalkan sigil baru hanya untuk jalur. Menerapkan :: di awal ::crate::foo sudah cukup untuk mengatasi komentar @glaebhoerl dan menghilangkan ambiguitas penguraian. Itu juga cocok dengan model mental yang dimaksudkan untuk crate:: lebih dekat- ini adalah pengganti untuk nama peti saat ini, bukan awalan jalur seperti self:: .

(Secara umum, memiliki jalur relatif dan absolut yang dimulai dengan :: telah menjadi sumber rasa sakit berkali-kali, adalah kebenarannya.)

Saya tidak yakin apa yang Anda maksud dengan ini. Saya rasa tidak ada jalur relatif yang dimulai dengan :: , bukan?

@nikomatsakis @glaebhoerl terlepas dari apakah saya suka saran Anda atau tidak (saya sebenarnya bisa hidup dengan keduanya), bisakah kita tetap berpegang pada RFC? Ini telah dibahas bolak-balik dalam banyak cara dan saya tidak berpikir bahwa membuka debat lagi akan membantu siapa pun. Sebanyak 82 orang telah mengomentari utas RFC terbaru (sebelumnya ada beberapa diskusi), banyak yang merasa sangat kuat tentang hal itu. Saya pikir tidak adil bagi mereka untuk menyelinap di menit-menit terakhir perubahan proposal pada saat ini, tanpa memberi mereka kesempatan untuk meninjau perubahan.
Terutama saya agak bingung karena di #44721 @nikomatsakis menutup diskusi tentang fitur dengan argumen "mari kita bicara tentang implementasinya saja".

Notasi @ dan [] keduanya telah diusulkan (dengan saya menjadi pendukung keduanya) tetapi mereka akhirnya tidak berhasil, setidaknya itulah kesan saya, karena tanggapan negatif dari pengguna .

Bahkan jika tidak ada kasus sama sekali di mana :: terkemuka dapat dikacaukan dengan jalur yang dimulai pada pengidentifikasi sebelumnya dan memiliki internal :: , itu tidak terlalu berbeda secara visual.

Juga, itu kurang sugestif. @ adalah mnemonik yang lebih baik. Dengan awalan :: Anda harus bertanya-tanya apakah itu seperti jalur nama file, di mana awalan / berarti root (jika Anda menggunakan sistem Unixy), atau apakah itu singkatan standar, di mana tidak ada awalan hal akan berarti "kami meninggalkan nama karena itu relatif". Dengan berpikir sejenak Anda dapat melihat bahwa yang pertama lebih masuk akal, tetapi intinya adalah bahwa itu membutuhkan pemikiran sejenak. @ (atau semacamnya) langsung dapat dibedakan baik oleh kompiler maupun pembuat kode, membuatnya lebih mudah untuk langsung memahami apa yang sedang terjadi.

Bagaimana @ terkemuka lebih mudah dibedakan daripada :: terkemuka? :: sudah menjadi mekanisme yang mapan baik di Rust maupun C++!

@rpjohnst - Saya mengatakan bagaimana dalam kalimat yang Anda tanggapi! @ berbeda secara visual. Untuk memperluas: itu melompat ke arah Anda. Tidak ada bahaya memimpin vs. pemosisian internal menjadi bingung dalam model mental Anda dari aliran token.

@ adalah token yang benar-benar baru tanpa arti apa pun, dan akan membutuhkan lebih dari "pemikiran sesaat" untuk mengetahuinya. Membingungkan terkemuka :: untuk internal :: bukan masalah untuk memulai dengan- tidak ada alasan siapa pun harus mengambil "berpikir sejenak" untuk mengabaikan gagasan bahwa terkemuka :: mungkin jalur relatif.

@rpjohnst - Pernyataan Anda benar jika diberikan pelatihan yang memadai tentang arti :: (yang disediakan oleh pengalaman dengan C++ atau Rust). Saya berbicara tentang kemampuan belajar dan perbedaan intrinsik. "Simbol yang sama digunakan dalam konteks yang berbeda" tidak akan pernah dapat dibedakan seperti "simbol yang unik".

Saya dapat menerima argumen bahwa tidak ada gunanya membakar @ sebagai simbol unik pada kasus penggunaan seperti ini di mana ada alternatif yang dapat ditoleransi.

@Ichoran : Saya pikir menambahkan token baru untuk semantik tertentu ( @ ) ke tata bahasa Rust bukanlah langkah yang bisa dianggap enteng, dan saya agak curiga kita terlalu dekat untuk melakukannya dengan @nikomatsakis dan usulan orang lain. Pertama, karena kita kemudian tidak dapat menggunakannya kembali untuk tujuan lain di kemudian hari dalam kehidupan bahasa (saya kira jalur sangat meresap dalam kode sehingga token @ dapat muncul di banyak tempat). Saya juga bertanya-tanya apa efeknya pada persepsi kompleksitas kode Rust. Untuk pemula yang tidak terbiasa misalnya C++, saya percaya (tetapi tidak memiliki penelitian tentang ini) Rust adalah bahasa dengan notasi yang cukup barok dan mengintimidasi. Salah satu tujuan strategis untuk tahun ini adalah untuk mengoptimalkan kemampuan belajar dan saya kira kemudahan didekati dari Rust. Jadi mungkin kita harus mempertimbangkan ini ketika menyukai @ karena intuisinya akan menonjol dalam kode (yang menurut saya @rpjohnst ). Apakah saya cukup jelas apa yang saya maksud dengan ini?

(Jangan ragu untuk mengoreksi atau mengklarifikasi apa pun yang saya klaim, karena saya tidak punya waktu untuk mengikuti diskusi tentang tata bahasa Rust begitu dekat.)

@est31

terlepas dari apakah saya menyukai saran Anda atau tidak (saya sebenarnya bisa menerima keduanya), bisakah kita tetap berpegang pada RFC?

Pada dasarnya saya setuju. Saya tidak benar-benar ingin terlibat dalam diskusi besar sekarang -- ini adalah periode impl! -- tapi saya memang ingin meletakkan ide @ "di luar sana" untuk membara di latar belakang. Sebagian, karena saya cenderung menjadi pelupa, dan menulis sesuatu membantu saya untuk mengingatnya nanti.

Perasaan saya adalah bahwa pada titik ini hal yang benar untuk dilakukan adalah:

• Menerapkan RFC kira-kira seperti yang tertulis.
  
  
  
  • Kami mungkin ingin, misalnya, mengadopsi saran @rpjohnst tentang ::crate untuk jalur absolut, hanya untuk menyelesaikan disambiguitas penguraian, karena sepertinya delta yang sangat kecil, dan sebenarnya meningkatkan konsistensi secara keseluruhan.
  
  
• Dapatkan pengalaman dalam menggunakannya.
• Tinjau kembali desainnya, dengan mengingat alternatif yang telah diajukan sementara itu, dan buat keputusan stabilisasi akhir.

Ini adalah semangat yang saya maksudkan untuk menulis komentar saya, meskipun saya kira saya tidak menjelaskannya. Mungkin akan lebih baik untuk menyimpannya dalam file pribadi. :wanita_mengangkat bahu:

EDIT: Juga, saya sadar bahwa @ dan [] dinaikkan lebih awal, meskipun saya tidak ingat apakah notasi @::foo disebutkan sebelumnya karena relatif terhadap saat ini peti. Jadi saya tidak bermaksud mengklaim kepengarangan ide tersebut.

OTOH, ide yang saya sebutkan belum pernah diangkat sebelumnya, dan bukan merupakan modifikasi dari RFC sebagai perpanjangan darinya. Juga, "Sintaks terakhir untuk jalur absolut; ada lebih banyak pelepasan sepeda yang harus dilakukan di sini dalam konteks di mana kita dapat benar-benar mencoba berbagai opsi." secara eksplisit terdaftar sebagai pertanyaan yang belum terselesaikan di badan masalah. Saya setuju bahwa, secara umum, kita harus mencoba untuk menghindari litigasi ulang RFC yang diterima, tetapi saya tidak merasa situasi ini sebanding dengan yang kita miliki dengan misalnya rentang inklusif (ugh).

Lihat juga utas diskusi ini:

https://internals.rust-lang.org/t/the-great-module-adventure-continues/6678

Selamat datang di episode lain dari Petualangan Modul Hebat! Ketika terakhir kali kami bertemu, petualang pemberani kami akhirnya datang ke negeri dongeng, setelah menerima RFC #2126. Di sana mereka beristirahat sejenak, dan bersiap untuk memulai Periode Impl. Pada periode itu, banyak pekerjaan yang dilakukan, dan memang garis besar sistem modul mulai diimplementasikan. Tapi lihatlah, masih ada beberapa pertanyaan yang mengganggu untuk diselesaikan… dan itu membawa kita ke utas diskusi ini.

Dalam bahasa yang kurang berbunga-bunga: selama periode impl, kami membuat banyak kemajuan dalam mengimplementasikan RFC “Menjelaskan dan menyederhanakan jalur dan visibilitas” (bersama dengan sejumlah RFC terkait). Faktanya, kami membuat terlalu banyak kemajuan – kami menerapkan beberapa varian berbeda, dan saya ingin memulai diskusi tentang apa yang sebenarnya kami inginkan.

Saya ingin dapat menstabilkan pekerjaan yang luar biasa ini suatu hari nanti =) dan itu akan mengharuskan kami memilih salah satu varian ... karenanya utasnya.

Secara pribadi saya penggemar sintaks @ disebutkan oleh @nikomatsakis. Ini ringkas, dan cukup jelas. Kita akan harus diperkenalkan semacam sintaks baru di sini, jadi lebih baik char khusus dari nama cadangan seperti crate (ugh).

Sepertinya kita berada dalam posisi untuk menangani pointer luar kedua sekarang, terutama mengingat https://github.com/rust-lang/cargo/issues/1311 sekarang diselesaikan (seharusnya sudah ditutup, sebenarnya). Saya mungkin bisa mengatasi ini, dengan sedikit bimbingan, dan keputusan tentang sintaks @ vs. crate . Pikiran?

Menambahkan masalah pelacakan untuk dua lint yang tidak diterapkan.

Terpikir oleh saya bahwa kita memiliki masalah kompatibilitas kecil: jika kita ingin extern crate menjadi implisit, ada perubahan besar yang terlibat dalam membuat pekerjaan itu -- extern crate memaksa peti untuk ditautkan; yang dapat menyebabkan kesalahan jika Anda menentukan peti ekstra di Cargo.toml tetapi bukan lib.rs yang tidak saling terhubung dengan bersih (misalnya panic=unwind peti dengan panic=abort, atau peti yang mengekspor simbol yang sama). Sudahkah kita menentukan ini sebagai kerusakan yang tidak bermasalah?

Terpikir oleh saya bahwa kita memiliki masalah kompatibilitas kecil: jika kita ingin peti eksternal menjadi implisit, ada perubahan besar yang terlibat dalam membuat pekerjaan itu -- peti eksternal memaksa peti untuk dihubungkan; yang dapat menyebabkan kesalahan jika Anda menentukan peti ekstra di Cargo.toml tetapi bukan lib.rs yang tidak saling terhubung dengan bersih (misalnya panic=unwind peti dengan panic=abort, atau peti yang mengekspor simbol yang sama). Sudahkah kita menentukan ini sebagai kerusakan yang tidak bermasalah?

Satu- satunya solusi yang saya lihat sejauh ini adalah hanya secara implisit menautkan peti ketika Anda mengimpor sesuatu dari peti itu, namun ini masih memiliki beberapa masalah. Ada banyak cara peti dapat mengekspos fungsionalitas dengan cara selain hanya mengekspor simbol karat untuk diimpor, seperti menautkan di pustaka asli tertentu atau mengekspor simbol #[no_mangle] untuk menyelesaikan beberapa dependensi di pustaka asli. Setelah extern crate dihapus, satu-satunya cara untuk memaksa peti tersebut ditautkan adalah dengan membuatnya mengekspor simbol karat plasebo untuk diimpor sesuai kebutuhan. Saya tidak tahu siapa yang berpikir itu adalah ide yang lebih baik untuk memaksa orang menggunakan solusi seperti itu daripada tetap berpegang pada extern crate .

Ya, kami secara eksplisit menggunakan pola ini di Firefox -- ada peti gkrust yang hanya berisi pernyataan peti eksternal untuk peti yang perlu ditautkan (ini mengekspos fungsi C eksternal yang ditulis dalam Rust yang dipanggil Firefox)

Anda masih bisa membuatnya bekerja dengan mengharuskan orang untuk use cratename; di lib.rs untuk memaksa ini.

Bagaimana dengan memiliki atribut #![link_crates(stylo,webrender)] untuk tujuan ini? Tidak seperti extern crate , itu tidak akan menambahkan peti ke pohon nama. Memberinya nama baru akan dengan jelas menunjukkan kepada pembaca bahwa Anda memasukkan peti untuk tautan saja dan bahwa pernyataan itu tidak boleh dihapus, sedangkan extern crate seharusnya.

Itu memecahkan masalah yang berlawanan?

Oh, begitu, untuk orang-orang di zaman 2015 ini memungkinkan mereka meningkatkan kode mereka tanpa beralih zaman.

Tapi ini berarti bahwa _everyone_ perlu menggunakan kunci link_crates . Itu tidak ideal.

Bagaimana dengan memiliki atribut #![link_crates(stylo,webrender)] untuk tujuan ini? Tidak seperti peti eksternal, peti itu tidak akan menambahkan peti ke pohon nama.

Bagaimana dengan peti yang dapat digunakan baik sebagai peti penghubung saja, sebagai peti dengan simbol Karat, atau keduanya?

@whitequark jika Anda menggunakan simbol dari peti itu, Anda akan mendapatkan tautan gratis seperti yang sudah terjadi sekarang. Atribut akan berada di situs penggunaan sehingga Anda sebagai pengguna memutuskan bagaimana menggunakan peti.

@Manishearth

Tetapi ini berarti bahwa setiap orang perlu menggunakan kunci link_crates. Itu tidak ideal.

Tidak. Saya belum mengutarakan proposal saya dengan cukup baik. Saya ingin mempertahankan bagian di mana use cratename::item; memiliki efek yang sama dengan link_crates tetap utuh. Fitur link_crates hanya boleh digunakan jika Anda tidak membutuhkan item apa pun dari peti tetapi membutuhkan tautan. Jika Anda mengimpor item apa pun dari peti, Anda akan mendapatkan tautan seperti yang diusulkan RFC.

Saya hanya tidak berpikir bahwa memiliki use cratename; dalam kode Anda untuk tujuan itu baik karena akan membingungkan serat dan (yang paling penting) pembaca/penulis kode, dan dengan demikian berpikir bahwa harus ada fitur khusus untuk itu yang sah (tapi jarang) menggunakan kasus.

@est31 Bikeshedding pada sintaks untuk link_crates , alih-alih menjadikannya sebagai atribut, mengapa kita tidak melakukan sesuatu seperti extern crate foo; ?

@retep998
Ide bagus! :senyum:
https://github.com/rust-lang/rfcs/pull/2166 bahkan memperkenalkan extern crate foo as _; untuk menghindari membawa nama peti ke dalam ruang lingkup/modul untuk peti khusus tautan.

@est31 Bikeshedding pada sintaks untuk link_crates, alih-alih menjadikannya sebagai atribut, mengapa kita tidak melakukan sesuatu seperti extern crate foo;?

Intinya adalah untuk menyingkirkan sintaks extern crate dalam jangka panjang.

@alexreg Intinya adalah membuatnya tidak diperlukan dalam kasus umum. Itu tidak berarti itu harus sepenuhnya diberantas, mungkin itu masih merupakan solusi yang bagus untuk kasus tepi peti yang perlu ditautkan tanpa item Karat darinya digunakan. (Lagi pula itu akan hidup selama kompiler mendukung zaman yang lebih lama.)

@SimonSapin Tapi bergerak maju, jika itu hanya akan menjadi kasus tepi, mungkin memiliki sintaks khusus untuk itu tidak masuk akal, dan atribut (seperti yang diusulkan di atas) akan lebih masuk akal.

Saya masih berpikir use foo atau use foo as _ seharusnya cukup di sini, kok

Setuju dengan @Manisharth.

Meringkas pandangan saya tentang extern crate; :

Keuntungan:

• extern crate memberi Anda daftar lengkap peti bekas tepat di bagian atas perpustakaan Anda. Sekarang dengan peti biasa, ini tidak begitu relevan karena ada Cargo.toml, tetapi jika Anda memiliki contoh, ini sangat berguna karena memberi Anda daftar peti untuk diimpor. Coba pikirkan, bagaimana jika contoh Anda hanya mengimpor sebagian dari dependensi dev Anda? Ini memiliki manfaat tinggi ketika mencoba mencari tahu API peti baru, alias manfaat kemampuan belajar. Di sisi lain Anda dapat menyebutkan bahwa extern crate dapat muncul di mana saja di dalam peti sehingga daftar tidak harus lengkap, tetapi untuk contoh ini kurang relevan. Kami selalu dapat mengubah peti eksternal untuk hanya berfungsi di root peti jika kami mau.

Kekurangan:

• extern crate adalah gangguan kecil karena itu berarti lebih banyak barang untuk diketik saat menambahkan peti. Saya pikir ini adalah alasan mengapa banyak orang menentang extern crate tetapi bagi saya itu bukan alasan yang memotivasi.
• Saya melihat extern crate menjadi bagian dari perdagangan: kami menyerahkan extern crate tetapi mendapatkan perbedaan antara peti-impor-dari-sendiri vs peti-impor-dari-eksternal. Ini adalah fitur yang jauh lebih berguna dan melebihi kerugian IMO yang dapat dipelajari dengan contoh/tes kode. Ini adalah alasan yang memotivasi mengapa saya setuju dengan penghapusan extern crate .

extern crate memberi Anda daftar lengkap peti bekas tepat di bagian atas perpustakaan Anda. Sekarang dengan peti biasa, ini tidak begitu relevan karena ada Cargo.toml, tetapi jika Anda memiliki contoh, ini sangat berguna karena memberi Anda daftar peti untuk diimpor.

Saya tidak melihat bagaimana ini relevan dengan diskusi di sini; ini adalah poin melawan RFC yang sudah digabungkan.

@Manisharth Saya lebih banyak membalas @retep998 di sini yang menyarankan untuk menyimpan peti eksternal. Dan tidak, suatu poin bukanlah tidak sah atau tidak relevan hanya karena bertentangan dengan RFC yang sudah digabungkan. Seseorang perlu merenungkan dan mengetahui keuntungan dan kerugian dari keputusan. Misalnya, kita masih dapat menghapus peti eksternal dari lib.rs tetapi menyimpannya untuk hello_world.rs untuk manfaat ergonomis dan kemampuan belajar (untuk pengguna perpustakaan, bukan penulisnya).

Itu tidak relevan karena hal yang sedang dibahas (dalam komentar Peter yang Anda balas) adalah peti tautan saja; yang merupakan kasus penggunaan yang cukup khusus sehingga "daftar semua peti eksternal Anda di atas" adalah manfaat marjinal. Terutama jika Anda memiliki dependensi yang juga _not_ peti tautan saja (Dulu ini tidak berlaku untuk Firefox, tetapi sekarang).

Jika poin Anda lebih umum tentang memiliki peti eksternal implisit yang tidak berlaku untuk pengujian (dan tidak secara khusus tentang peti tautan saja), itu poin yang menarik, tetapi saya tidak begitu setuju karena itu akan lebih membingungkan ketika digunakan hanya dalam setengah kode.

Jadi, jika saya tidak salah, satu-satunya titik implementasi yang tersisa di sini adalah #48719. Apakah ada yang menangani itu sekarang? Jika tidak, saya bisa pergi, saya kira ...

Ya, kami mencoba hal-hal di #50260

Pada Sabtu, 28 April 2018, 09:15 Alexander Regueiro [email protected]
menulis:

Jadi, jika saya tidak salah, satu-satunya titik implementasi yang tersisa di sini adalah

48719 https://github.com/rust-lang/rust/issues/48719 . Apakah ada orang?

menangani itu sekarang? Jika tidak, saya bisa pergi, saya kira ...

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rust-lang/rust/issues/44660#issuecomment-385187379 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ABivSMyg6L4nQ1O7nMcvY4JCGjWKRiq3ks5ttJWhgaJpZM4PaPPi
.

48722 selesai. @Manisharth bisakah Anda memperbarui OP, tolong :)

@mark-im @Manisharth https://github.com/rust-lang/cargo/issues/1311 juga selesai, jadi mungkin ada baiknya mengubah titik itu menjadi kotak centang dan mencentangnya. Saya ingin tahu: apa pendekatannya ketika Kargo tidak digunakan, ke depan? (Bukan berarti ada orang waras yang menghindari Kargo...)

@alexreg Mekanisme yang digunakan Cargo untuk memberi tahu rustc untuk mengganti nama peti sama-sama dapat diakses oleh orang yang tidak menggunakan kargo: --extern name_rustc_sees=path_to_dep.rlib .

Sepertinya kita akan segera menyelesaikan seluruh tahap implementasi – ketika https://github.com/rust-lang/rust/pull/47992 mendarat, sebenarnya. Apakah saya kehilangan sesuatu? Dengan senang hati membantu memindahkan ini jika ada bagian yang tersisa untuk dilakukan.

Ya, sedang dalam perjalanan. Saya harus menyelesaikannya yang kemungkinan besar akan saya lakukan lebih awal
minggu depan.

Pada Thu, 3 Mei, 2018, 7:51 Alexander Regueiro [email protected]
menulis:

Sepertinya kita akan segera menyelesaikan seluruh tahap implementasi – kapan

47992 https://github.com/rust-lang/rust/pull/47992 mendarat, sebenarnya. Saya

Saya melewatkan sesuatu? Dengan senang hati membantu memindahkan ini jika ada sedikit dan
bobs yang tersisa untuk dilakukan.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rust-lang/rust/issues/44660#issuecomment-386494018 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ABivSDYFonDWvxZEdxWXoykroaL2mJPxks5tu8I_gaJpZM4PaPPi
.

@Manisharth Barang bagus.

@aturon dengan https://github.com/rust-lang/rust/pull/50260 mendarat, apakah semuanya diimplementasikan?

Adakah yang punya tautan ke rencana yang diusulkan setelah RFC? Yang lebih mirip dengan apa yang sebenarnya diterapkan? (di mana impor peti --extern ditambahkan ke pendahuluan, dan lain-lain.)

Ditemukan: https://internals.rust-lang.org/t/the-great-module-adventure-continues/6678/205

Karena ini adalah perubahan yang signifikan, mungkin RFC harus diperbarui?

RFC umumnya tidak diperbarui; mereka bukan spesifikasi akhir. Mereka adalah
alat untuk membangun konsensus.

Pada Sen, Jun 18, 2018 at 21:43 PM, Siapa? Saya?! [email protected] menulis:

Karena ini adalah perubahan yang signifikan, mungkin RFC harus diperbarui?

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rust-lang/rust/issues/44660#issuecomment-398247665 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AABsij-Iwwb7vf4qBrsq9KFFqhuIbkVBks5t-Fc3gaJpZM4PaPPi
.

@mark-im Postingan wacana itu tetap berada di dalam semangat RFC. Bandingkan ringkasan RFC dengan posting itu, sebagian besar sama, di luar detail kecil. Ada RFC di mana tim memutuskan untuk melakukan perubahan yang sama sekali berbeda, tetapi ini bukan salah satunya.

Itu semua benar, tetapi alangkah baiknya jika semuanya berada di satu tempat. Saya mengerti tantangan logistik itu meskipun ...

Perhatikan bahwa Pratinjau Edisi awal

@aturon Pembaruan terakhir, dan pertemuan terakhir kelompok kerja modul, menghasilkan https://internals.rust-lang.org/t/the-great-module-adventure-continues/6678/205 , yang secara khusus mengatakan " dipersempit menjadi proposal inti tunggal, dengan dua varian". Sejauh pengetahuan saya, itu masih benar. Saya mendapat kesan bahwa nightly telah mengimplementasikan keduanya, melalui flag fitur, untuk mendukung eksperimen dengan keduanya.

Tampaknya edisi tersebut memilih salah satu dari dua varian, memilihnya untuk mendukung tanpa tanda fitur, dan mendokumentasikannya dalam panduan edisi. Di mana itu dibahas? Karena sejauh yang saya tahu, baik pokja modul maupun tim lang tidak terlibat di sana.

Silakan lihat https://internals.rust-lang.org/t/relative-paths-in-rust-2018/7883 untuk proposal baru, yang dibuat dari pratinjau 2018. Secara khusus, proposal ini memberikan lebih banyak konsistensi dan keseragaman antara modul root dan submodul, dan menggunakan resolusi nama yang sama baik dalam pernyataan use dan dalam penggunaan langsung jalur dalam kode.

Hai, hanya 2 sen saya di ::some::path vs crate::some::path - Saya lebih suka yang terakhir, terutama karena lebih mudah dibaca sebagai bahasa Inggris biasa dan tidak meninggalkan tanda baca gantung kiri yang gila.

Silakan lihat dan tinggalkan umpan balik di sini!

Saya harap ini yang Anda maksud. Setelah meninjau perubahan besar pada peti berjangka, di mana semua pub(crate) s diubah menjadi crate , saya lebih yakin bahwa menggunakan crate baik dalam impor maupun sebagai visibilitas modifikator terasa tidak wajar dan membingungkan.

crate enum Either<T, U> {
    A(T),
    B(U),
}

Saya merasa sangat membingungkan ketika keduanya digunakan bersama:

crate use crate::foo;

Seperti yang saya sebutkan dalam masalah lint untuk mencoba membuat kita semua beralih , itu akan membuat saya sangat sedih, dan saya mungkin ingin lint pihak ke-3 diimplementasikan untuk melakukan yang sebaliknya, untuk digunakan di perpustakaan yang saya pertahankan: menghentikan orang dari mengonversi pub(crate) menjadi hanya crate .

(Catatan: Saya tidak mengomentari bagian lain dari perubahan, yang tampaknya bagus untuk konsistensi, hanya perubahan dari pub(crate) menjadi crate .)

@seanmonstar Dengan usulan perubahan tambahan pada sistem modul di pratinjau edisi berikutnya, saya berharap crate::foo akan menjadi lebih jarang, dan crate use crate:: sepertinya merupakan kejadian yang sangat langka.

Dengan sistem modul di pratinjau awal 2018, Anda harus menulis crate:: bahkan untuk referensi lebih dalam ke peti Anda. Dengan sistem modul yang diusulkan, Anda hanya akan perlu crate:: referensi dalam peti Anda (misalnya, dari foo.rs ke lib.rs, atau dari foo / bar.rs untuk foo.rs), tetapi bukan untuk referensi ke dalam peti Anda (misalnya, dari lib.rs ke foo.rs, atau dari foo.rs ke foo / bar.rs). Dan secara umum, saya mengharapkan ekspor ulang (baik melalui pub use atau crate use ) untuk mengekspor kembali sesuatu dari modul yang lebih dalam di modul tingkat yang lebih tinggi, bukan sebaliknya.

Jadi secara umum saya akan terkejut melihat crate use crate::foo; .

Namun, dalam proyek saya kerjakan, saya memiliki tepat skenario ini. Saya memiliki modul yang berisi beberapa pembantu "generik", dan kemudian modul lain yang mendefinisikan sifat dasar + kombinator, dan karena mereka menggunakan beberapa pembantu generik, saya telah mengekspor ulang untuk membantu diri saya sendiri di bagian lain dari peti:

Saat ini:

// in filter/mod.rs
pub(crate) use ::generic::{Combine, Func};

// in filters/foo.rs
use ::filter::{Filter, Func};

Lint ingin saya mengubah ini menjadi:

// in filter/mod.rs
crate use crate::generic::{Combine, Func};

Jadi, saya tidak mencoba membuat hipotesis yang tidak akan pernah ditemui siapa pun. Itu nyata.

Saya sepenuhnya setuju dengan @seanmonstar. Mari kita tidak membebani kata kunci ini kecuali kita harus (yang tidak kita lakukan).

Ya, Anda benar bahwa mengekspor ulang _biasanya_ menggelembung, tetapi mengekspor ulang _lateral_ juga merupakan suatu hal, seperti yang dijelaskan Sean. Itu adalah sesuatu yang saya pertimbangkan untuk dilakukan untuk peti media servo juga, karena file-file tersebut dibagi dengan cukup baik tetapi itu hanya berarti banyak impor umum di semua implementasi simpul kami.

Apakah mungkin untuk terus mendeklarasikan apa yang digunakan dalam modul dan mungkin memerlukan penggunaan eksplisit, mungkin sebagai atribut peti? Saya lebih suka dapat mengetahui dengan melihat file sumber apa yang ada dalam ruang lingkup di dalamnya. Memiliki beberapa baris impor tingkat root di awal file sumber membantu memberikan konteks untuk apa yang sebenarnya terjadi di dalamnya, daripada hanya memiliki semua dependensi eksternal secara implisit dalam cakupan, dan sangat membantu saat refactoring.

Setelah mencoba konversi di salah satu peti saya, saya ingin menyebutkan seperti beberapa orang lain yang pernah saya lihat membicarakan hal ini, saya tidak yakin menggunakan crate sebagai pengubah visibilitas alih-alih pub(crate) adalah sebuah perbaikan. Alasan saya di sini adalah bahwa moniker peti cukup banyak digunakan, dan hanya menempelkannya di depan item membuatnya sedikit berantakan (ini mengingatkan saya pada kata kunci sup yang Anda dapatkan dalam beberapa bahasa, seperti Java public static void main() -- setidaknya Rust memiliki tipe pengembalian di bagian akhir). pub(crate) setidaknya mempertahankan pub untuk membuatnya lebih jelas bahwa crate berhubungan dengan visibilitas dalam konteks ini.

Berikut ini contoh lain yang baru saja saya temui yang menggabungkan kata kunci crate di pengubah visibilitas dan jalur, yang tampaknya lebih mungkin daripada contoh crate use crate... .

Saat ini:

pub(crate) struct Bar {
    pub(crate) foo: ::Foo,
}

pub(crate) struct Baz(pub(crate) ::Foo);

Dengan perubahan dari masalah pelacakan ini:

crate struct Bar {
    crate foo: crate::Foo,
}

crate struct Baz(crate crate::Foo);

Saya pribadi menemukan yang baru lebih membingungkan daripada cara saat ini.

Ketika saya pertama kali membaca RFC untuk mengonversi pub(crate) menjadi crate saya pikir itu terdengar seperti tidak perlu dipikirkan lagi. pub(crate) terlihat sangat aneh dibandingkan dengan sintaksis Rust lainnya di area ini.

Tetapi...

Setelah mengonversi sedikit permainan Piston ke Rust 2018 dan melihatnya secara langsung, saya harus mengakui bahwa saya bersimpati pada komentar @seanmonstar dan lainnya bahwa memiliki crate telanjang yang ditaburkan di mana-mana secara kognitif menggelegar. Saya tidak yakin apakah saya secara alami akan terbiasa dengan ini dari waktu ke waktu atau tidak.

Seperti yang dikatakan orang lain, rasanya seperti kata kunci berarti sesuatu yang sangat berbeda di kedua konteks.

use crate::menu::{Sound, Volume};

crate mod color;

...

/// A type for storing text and an associated color it should
/// be drawn as.
crate struct ColoredText {
    crate color: types::Color,
    crate text: &'static str,
}

Saya ingin memperjelas bahwa saya sangat menyukai sisa proposal ini (pembaruan sistem modul).

Saya bersimpati bahwa pub(crate) tampaknya sedikit berat dan juga aneh, tetapi juga crate telanjang terasa sedikit tidak pada tempatnya.

Bisakah kita mempertimbangkan kata kunci yang berbeda di sini daripada menggunakan kembali crate ?

@neon64 Menyarankan internal yang terdengar masuk akal, tetapi mungkin ada yang lain. Karena kami dapat menambahkan kata kunci di Rust 2018, kami sekarang memiliki kesempatan untuk mempertimbangkan hal ini.

internal tampaknya lebih berat dari pub(crate) bagi saya. Ini tidak lebih pendek dan ini adalah kata kunci baru.

Bagaimana dengan int ? :P

Di dalam ( ins ), internal ( int ), dilindungi ( pro ), lokal ( loc ), rahasia ( sec ), inner ( inn ) ada banyak alternatif untuk kata kunci crate .

Apakah int akan membingungkan pengembang C/C++? (Kata kunci bilangan bulat)

sebagai seorang programmer, ketika Anda melihat pub Anda memperlakukannya sebagai publik, jika Anda ingin memperkenalkan tingkat visibilitas lain maka Anda perlu menjadi kata sifat agar tetap konsisten. Sejauh yang saya ingat pub berdiri untuk publish awalnya dan dalam kedua kasus pub(crate) terasa lebih alami. Crate hanyalah kata kunci aneh untuk itu.
Saya pikir lebih baik meninggalkan pub(crate) apa adanya atau menambahkan singkatan dari kata sifat.

juga saya pikir kesulitan dengan penamaan pergi dari fakta bahwa pub adalah singkatan, jika publik saya pikir tidak akan menjadi masalah untuk menyebutnya pribadi atau internal dan melupakannya.

Secara pribadi saya tidak melihat masalah dengan pub(crate) . Sintaksnya jelas dan tidak ambigu pada pandangan pertama dan konsisten dengan Rust yang sebenarnya. Saya tidak berpikir Anda harus mengetik ini cukup sering sehingga 5 penekanan tombol tambahan menjadi masalah.

@UtherII

Alasan mengapa kita membutuhkan nama pendek untuk pub(crate) adalah karena banyak (bahkan mungkin sebagian besar ) penggunaan pub ini akan diganti dengan itu.

Di Rust 2018, menggunakan pub untuk item pribadi yang efektif (karena muncul di modul pribadi) akan menjadi peringatan. Seseorang harus menggunakan pub(crate) untuk item seperti itu. Konvensi ini akan meningkatkan keterbacaan kode: sebuah item terlihat oleh peti lain jika dan hanya jika ditandai pub , sementara saat ini apakah itu terlihat oleh peti lain mungkin tidak terlihat secara sekilas.

Maaf, saya tidak sengaja membuat masalah baru untuk ini daripada menanggapi utas ini. Ups, saya agak baru di github dan cukup mengklik tombol yang menyebabkan saya masuk ke apa yang saya pikir merespons di sini tetapi sebenarnya membuat masalah baru. Saya akan menempelkan apa yang saya tulis di edisi baru di sini, dan masalah baru saya dapat dihapus, maaf tentang itu.

Melihat manual edisi menyarankan orang meninggalkan umpan balik di sini, saya memutuskan untuk melakukannya.

Saya tidak keberatan baik crate:: atau :: untuk mengakses elemen dari root crate. :: adalah sintaks yang sudah ada, jadi jika mungkin untuk memiliki keduanya crate:: dan :: Saya pikir keduanya harus digunakan. Cara saya melihatnya adalah bahwa sistem peti baru yang disarankan mengenai jalur pada dasarnya setara dengan sintaks lama, dengan satu-satunya perbedaan adalah Anda tidak perlu lagi menggunakan kata kunci extern, dan hal-hal lebih mudah diakses daripada perlu menggunakannya secara eksplisit dalam submodul mereka pada dasarnya diimpor secara implisit di mana-mana.

Satu-satunya tambahan lain tampaknya Anda memulai root peti dengan crate:: daripada ::. Saya lebih suka memulainya hanya dengan ::, karena ini konsisten dengan cara saya awalnya mempelajarinya, namun saya dapat melihat orang-orang yang belum mempelajari sistem modul namun menemukan memulainya dengan crate:: lebih intuitif. Mengapa tidak mengizinkan kedua bentuk sintaks? Apakah ada alasan yang membuatnya tidak layak untuk memiliki keduanya? Jika keduanya dapat didukung, saya sangat mendukung mendukung keduanya. Jika hanya satu yang dapat didukung, saya cenderung lebih ke arah :: seperti yang sudah biasa saya lakukan, meskipun mungkin lebih mudah bagi pemula untuk mempelajarinya sebagai peti :: dan saya dapat dengan mudah memperbarui pemahaman saya tentangnya untuk menjadi seperti itu, jadi mungkin motivasi saya egois.

Jadi intinya, saya pada akhirnya tidak terlalu peduli, tetapi saya pribadi lebih suka ::, tetapi saya pikir mendukung keduanya akan ideal, meskipun jika salah satu harus dipilih dan orang berpikir bahwa memulai dengan crate:: lebih unggul untuk pemula maka saya tidak tidak keberatan dengan ini.

Bagaimana #[path] seharusnya bekerja dengan modul bersarang di Rust 2018 ? (https://github.com/rust-lang/rust/issues/35016#issuecomment-409185342)

IIUC, saat ini, diberikan dua file src/lib.rs dan src/bar.rs , tidak ada X yang dapat diganti:

mod foo {
    #[path = "X/bar.rs"]
    mod bar;
}

sehingga modul bar.rs akan ditemukan, karena path ke bar.rs akan selalu src/foo/X/bar.rs yang tidak valid karena direktori foo tidak ada.

Karena kami melakukan bikeshed atas nama bagus untuk penggantian pub(crate) dan tim inti masih mencari umpan balik, saya ingin berbagi pengalaman dan menawarkan saran.

Dalam satu peti yang saya tulis, saya menemukan mengetik pub(crate) mana-mana membuat marah. Jadi saya hanya mempersingkatnya menjadi pub dan secara tidak sengaja mengekspor banyak simbol yang tidak perlu terlihat di luar peti. Ups. (Dalam kasus khusus saya itu tidak terlalu menjadi masalah, karena peti itu internal dan tidak dipublikasikan, tapi tetap saja! Kenyamanan daripada kebenaran.) Jadi ya, saya sangat yakin kita membutuhkan sesuatu yang lebih baik daripada gabungan dua kata kunci untuk menyampaikan visibilitas tingkat peti .

Tapi saya tidak percaya crate adalah kata kunci yang tepat untuk itu (lihat di atas untuk umpan balik dari orang lain tentang topik ini), dan saya merasa seperti beberapa kata kunci yang disarankan lainnya tidak tepat sasaran dengan mendekati masalah dari perspektif dari akar peti; masalahnya terletak pada perspektif modul, yaitu baris kode tertentu yang berisi kata kunci. Dengan kata lain, kode tidak mencoba memberikan "lokalitas peti", tetapi mencoba mengekspor referensi dari modul tempat ia didefinisikan.

Dalam hal itu, saya suka kata kunci export (walaupun mungkin membingungkan dengan extern , tapi mungkin itu diperdebatkan karena extern crate sudah mati?) export struct Foo; terlihat sangat mudah dibaca, dan sejajar dengan beberapa bahasa lain (ish). Saya tidak dapat menemukan penyebutan export sebagai kata kunci, di RFC ini atau di tempat lain. Jadi ada juga yang melakukannya.

Untuk kelengkapan, ini mencakup kasus penggunaan yang dibawa oleh @seanmonstar , @johnthagen , et al.:

export use crate::generic::{Combine, Func};

// Or even better using relative paths
export use ::generic::{Combine, Func};

export struct Bar {
    export foo: crate::Foo,
}

export struct Baz(export crate::Foo);

use crate::menu::{Sound, Volume};

export mod color;

// ...

/// A type for storing text and an associated color it should
/// be drawn as.
export struct ColoredText {
    export color: types::Color,
    export text: &'static str,
}

Semua yang mengatakan, saya mendukung membunuh pub(crate) dengan api. Saya bahkan lebih suka crate , FWIW.

@parasyte Masalah yang saya lihat dengan export adalah bahwa hal itu dapat dikacaukan dengan "peti ini mengekspor ____" (untuk apa pub ), tetapi saya melihat bagaimana Anda menganjurkan a perspektif yang berbeda.

Sepertinya sebagian besar orang setuju bahwa pub(crate) tidak ideal, dan banyak yang telah menyuarakan keprihatinan bahwa kata kunci kata benda crate , yang sekarang digunakan dalam konteks lain, dapat menggelegar sebagai penggantinya. Memastikan bahwa kami telah sepenuhnya mempertimbangkan kata kunci lain (yang berpotensi baru) sepertinya akan sangat berguna sebelum Rust 2018 menetapkannya.

Saya belum mendengar umpan balik "resmi" jika ini masih terbuka untuk diskusi?

Untuk memperkenalkan beberapa kata lagi di sepanjang baris saran @parasyte (saya setuju dengan @johnthagen bahwa export lebih mirip pub daripada pub(crate) ):

shared use ::generic::{Combine, Func};
shared struct ColoredText {
    export color: types::Color,
    export text: &'static str,
}

global use ::generic::{Combine, Func};
global struct ColoredText {
    export color: types::Color,
    export text: &'static str,
}

Kami juga dapat mengikuti jejak Java dan menggunakan sesuatu seperti protected , tetapi saya tidak yakin bahwa pemahaman itu mudah dipahami. Ada juga local (dalam arti crate-local), tapi menurut saya global sebenarnya lebih kecil kemungkinannya untuk membingungkan (misalnya, local bisa jadi _file_-local).

Bagaimana perasaan orang tentang pub(cr) atau bahkan hanya cr ?

Menggunakan crate tampaknya terlalu bagus untuk dilewatkan. Ini sudah menjadi kata kunci, penggunaan sebelumnya di extern crate akan dihentikan. Penggunaan lainnya sudah terkait dengan visibilitas pub(crate) .

Jika Anda menyipitkan mata sedikit menggunakan peti sebagai kata sifat tidak terdengar membingungkan. Kata-kata seperti 'rumah' dapat digunakan sebagai kata sifat dengan baik. IANAEnglishProfesor.

Saya pikir mengekspor kembali item peti yang terlihat tidak terlalu bermasalah. Secara pribadi saya hanya pernah mengekspor ulang item dalam induk langsung dari modul yang mendefinisikannya, yang berarti Anda (mungkin) ingin menggunakan self alih-alih crate (walaupun kasus pengorganisasian kode seanmonstar ). Misalnya.

    mod detail {
        crate struct Foo;
    }

    crate use self::detail::Foo;

Menggunakan peti sebagai visibilitas yang dikombinasikan dengan jalur absolut ke suatu tipe (sekali lagi menggunakan contoh seanmonstar) memang terlihat lebih bermasalah: crate struct Foo(crate crate::Bar); dibandingkan dengan pub(crate) struct Foo(pub(crate) ::Foo); . Satu-satunya harapan saya adalah bahwa konstruksi ini tidak populer dan dengan demikian transisi tidak akan membuat sup peti ini. Pengguna dapat menghindari ini dengan mengimpor secara eksplisit:

use crate::Bar;

crate struct Foo(crate Bar);

Saya suka saran share atau sesuatu seperti itu. give , provide , deliver , offer , serve , post , forward .. . Jika harus kata sifat, ini semua dapat diubah dengan akhiran: shared , givable , providable , dll.

Untuk memilih JavaScript sejenak, ES6 bahkan tidak memiliki konsep paket versus modul yang dibangun ke dalam bahasa. Hanya ada modul. Kata kunci export di ES6 selalu mengekspor referensi dari modul; itu kemudian hingga modul lain ke import referensi itu dengan jalur jika ingin menggunakannya.

Ini tidak jauh berbeda dari pub dan use , masing-masing. dan saya rasa dari situlah beberapa kebingungan akan muncul dengan menggunakan kata kunci export . pub(crate) sebenarnya adalah jenis niche. Itulah sebabnya saya memilih untuk hanya menggunakan pub di masa lalu. ;(

Masalah pengubah visibilitas crate telah diekstraksi ke #53120. Perdebatan dan keputusan lebih lanjut harus berlanjut di sana.

Masalah perubahan mod.rs telah diekstraksi ke #53125. Perdebatan dan keputusan lebih lanjut harus berlanjut di sana.

Masalah penghentian extern crate serta memiliki use crate_name::foo dan crate_name::foo Just Work™ telah diekstraksi ke https://github.com/rust-lang/rust/ masalah/53128. Perdebatan dan keputusan lebih lanjut harus berlanjut di sana.

Masalah memilih Sistem Jalur Modul telah diekstraksi ke https://github.com/rust-lang/rust/issues/53130.

Setelah mengekstrak semua bit dari masalah ini menjadi masalah yang terpisah; Dengan ini saya menutup yang satu ini.

@Centril : https://doc.rust-lang.org/unstable-book/print.html#extern_prelude tautan di sini. Di mana ini sedang dibahas? Jika info ini memang hilang, bisakah Anda menambahkannya ke OP?

@sanmai-NL dapatkah Anda menyegarkan ingatan saya tentang apa "pendahuluan eksternal" itu?

Jika itu hanya kemampuan untuk melakukan use some_crate::foo::bar; maka itu seharusnya https://github.com/rust-lang/rust/issues/53128.

Beberapa di antaranya sedang dibahas di https://github.com/rust-lang/rust/issues/54230.

@sanmai-NL Saya percaya bahwa masalah ini terutama untuk diagnostik.

extern_prelude adalah crate_name::foo::bar luar jalur use (impor).

@Centril

dapatkah Anda menyegarkan ingatan saya tentang apa "pendahuluan eksternal" itu?

Secara umum, "prelude" saat ini digunakan untuk semua nama yang berada dalam cakupan seluruh peti dan tidak dilampirkan ke modul tertentu. (Ada banyak dari mereka sebenarnya.)

@petrochenkov Jadi apa pendahuluan "eksternal" dalam kaitannya dengan itu?

@alexreg
Peti yang diteruskan dengan --extern berada dalam cakupan untuk seluruh peti tanpa dilampirkan ke modul tertentu.

Akan sangat bagus jika nugget info ini, tidak peduli seberapa fluktuatifnya, dicatat dalam beberapa sumber dokumentasi resmi. khususnya jika ada penyebutan konsep di luar, misalnya dalam buku Unstable. Saya tidak mengatakan pengelola yang menerapkan konsep ini harus melakukan itu.

@petrochenkov Terima kasih, masuk akal.

Setelah mengekstrak semua bit dari masalah ini menjadi masalah yang terpisah; Dengan ini saya menutup yang satu ini.

@Centril Pelacakan masalah di tautan versi beta saat ini di sini. Apakah Anda akan memperbarui komentar asli dengan informasi terbaru sehingga orang tidak perlu mengulang komentar?