C is Brittle D is Plastic

[user1234]

On Tuesday, 24 March 2026 at 14:36:57 UTC, H. S. Teoh wrote:
> On Tue, Mar 24, 2026 at 12:38:28PM +0000, user1234 via 
> Digitalmars-d wrote:
>> On Tuesday, 24 March 2026 at 10:36:19 UTC, Max Samukha wrote:
>> > On Monday, 23 March 2026 at 23:48:27 UTC, Walter Bright 
>> > wrote:
>> > 
>> > > So now we have a complicated 2-phase lookup that everybody 
>> > > likes.
>> > 
>> > Again, not everybody likes it.
>> 
>> I don't know what this "2-phases lookup system" is refering to 
>> (my interest in D started by 2014 let's say and I have the 
>> feeling that this is an older topic). What was the problem in 
>> first place ?
>
> In the beginning, D's symbol lookup mechanism was very simple 
> and straightforward: whenever an import statement is 
> encountered, symbols from an imported module are loaded and 
> injected into the symbol table at the current scope.  This is 
> straightforward to implement (you literally translate "import 
> xyz" as parsing xyz and adding its public symbols to the 
> current scope's symbol table).
>
> However, that led to counterintuitive behaviours like:
>
> 	void main() {
> 		myFunc("abc");
> 	}
> 	void myFunc(string text) {
> 		writeln(text);	// prints "abc"
> 		import std.conv;
> 		writeln(text);	// prints ""
> 	}
>
> Walter was very resistant to changing this behaviour, as all 
> proposed solutions involved "inelegant" complications in the 
> semantics and implementation of "import".  Eventually, however, 
> the crowd prevailed and Walter relented.
>
>
> T

Thanks.

I would not like to be rude and reopen old wounds but this looks 
more a problem of `text` being either a variable or a function 
and as D allows function calls without params to me it looks like 
it has never been a problem of lookup. Now imagine std.conv.text 
is a global variable. That does not change anything. Order of 
declaration matters in the local scope.

Anyway, despite of this curious change, the front-end is still 
fast.