Extended Type Design.

[Andrei Alexandrescu (See Website For Email)]

Reiner Pope wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Reiner Pope wrote:
>>> Andrei Alexandrescu (See Website For Email) Wrote:
>>>
>>>> We have talked about a design. In short, the intent is to define 
>>>> three flavors of immutability:
>>>>
>>>> a) final - a simple storage class controlling the immutability of 
>>>> the bits allocated for the symbol per se;
>>>>
>>>> b) const - type qualifier meaning an immutable view of an otherwise 
>>>> modifiable data. const does not control the bits of the object, only 
>>>> the storage addressed indirectly by it (transitively);
>>>>
>>>> c) "superconst" - denoted as "const!" or "super const": type 
>>>> qualifier meaning that the data is genuinely unmodifiable.
>>>>
>>> Is there anything in your discussion about compile-time constants 
>>> (the sort that you need for 'static if', etc) ? You spoke a while ago 
>>> about improving compile-time evaluation syntax so that there would be 
>>> no difference at the call  site between runtime and compile-time 
>>> evaluation (like for regexps).
>>
>> I understand this is high on Walter's list.
> Good to hear that.
> 
>  The syntax discussed is:
>>
>> // dispatched when the pattern is known at compile time
>> RegExpMatch match(const char[] p)(const char[] p, char[] text) {...}
>> // dispatched when the pattern is a runtime string
>> RegExpMatch match()(const char[] p, char[] text) {...}
> That seems fine, but I can't help wondering, "why the double-declaration 
> of p in the first instance?" and also, "why does the second instance of 
> match even need to be a template?".

Good question. It must be a template by the pigeonhole principle: each 
compile-time regex generates in theory different code, so you must have 
as many distinct functions as strings.

>>> It seems like you could get this quite easily by adding just one more 
>>> parameter modifier (is this a storage class? I'm not sure) to denote, 
>>> "any time this function is called, this parameter must be known at 
>>> compile-time". Effectively, it would just be a conversion from this:
>>>
>>> RegExpMatch match(static const char[] pattern, char[] text) {...}
>>> ...
>>> main()
>>> {
>>>      match("gr[ae]y", din.read());
>>> }
>>>
>>> to this:
>>>
>>> RegExpMatch match(char[] pattern)(char[] text) {...}
>>> ...
>>> main()
>>> {
>>>      match!("gr[ae]y")(din.read());
>>> }
>>>
>>> Any plans this way?
>>
>> The above forces only compile-time constant regexps. What we need is 
>> to dispatch depending on compile-time constant vs. run-time string.
> Well, I kind of took it for granted that the above suggestion would 
> allow for overloading by compile-time-constness (with a preference to 
> the compile-time version when there's a choice). So that you could write:
> 
> RegExpMatch match(static const char[] pattern, char[] text){...}
> RegExpMatch match(char[] pattern, char[] text) {...}
> 
>>
>> Combined with macros, this will essentially allow a call to writefln 
>> to morph, depending on its arguments, into putch(), fputs(), write(), 
>> fprintf() - or execute today's dynamically-checked writefln.
> 
> True. I was also interested in another use of this, though: allowing a 
> library-time implementation of tuples (since what kind of feature is one 
> that can't be implemented in the library?). There are basically two 
> reasons that this can't be done at the moment:
> 
> alias Tuple!(int, double) myTuple;
> myTuple[0] = 5; // First reason
> foreach (val; myTuple) // Second reason
> {
>     writef(val);
> }
> 
> I would imagine that you could implement the first feature as:
> 
> struct MyTupleImpl(TypeList...)
> {
>    ...
>    TypeList[i] opIndex(static const int i) {...}
> // We grab the return type based on the parameter, so we must know it at 
> compile time. It makes no sense to have a runtime version of this.
> }
> 
> and at a stretch, you could imagine the second feature as working in a 
> similar way: your compile-time representation of the foreach delegate is 
> either a char[] to be mixed in, or an expression alias, when we get that:
> 
> struct MyTupleImpl(TypeList...)
> {
>     int opApply(static const char[] code)
>     {
>         // iterate through tuple; this iteration would actually have to 
> be generated with CTFE, but you get the idea
>         {
>             TypeList[i] __special_foreach_key = whatever;
>             mixin(code);
>         }
>     }
> }

That's not on the list yet. One thing at a time :o).


Andrei