Better assert's status? (Was: Proposal for std.path replacement)

[spir]

On 03/07/2011 02:36 PM, Jacob Carlborg wrote:
> On 2011-03-07 13:55, spir wrote:
>> On 03/07/2011 07:20 AM, Jonathan M Davis wrote:
>>> On Sunday 06 March 2011 21:57:30 Nick Sabalausky wrote:
>>>> "Jonathan M Davis"<jmdavisProg at gmx.com> wrote in message
>>>> news:mailman.2293.1299467610.4748.digitalmars-d at puremagic.com...
>>>>
>>>>> On Sunday 06 March 2011 18:08:49 Andrei Alexandrescu wrote:
>>>>>> Yah, thing is people work on stuff they care about, not the most
>>>>>> urgent
>>>>>> stuff - surprise! :o) As such we don't have a ton of proposals for
>>>>>> networking and xml, but we do have one (and I won't argue it's a bad
>>>>>> one) for rehashing a module that basically worked.
>>>>
>>>> I'm not sure I'd say the current std.path "basically works", but I
>>>> get what
>>>> you mean.
>>>>
>>>>> I _was_ thinking of putting forward a new proposal which includes the
>>>>> unit testing functionality that assertPred had which won't end up in an
>>>>> improved
>>>>> assert,
>>>>
>>>> Speaking of which: Now that assertPred has been rejected on the
>>>> grounds of
>>>> an improved assert that doesn't yet exist, what is the current status of
>>>> the improved assert?
>>>
>>> There's an enhancement request for it:
>>>
>>> http://d.puremagic.com/issues/show_bug.cgi?id=5547
>>>
>>> I have no idea of any work is actually being done on it or not. It hasn't
>>> actually been assigned to anyone yet, for whatever that's worth.
>>> Honestly, it
>>> wouldn't surprise me if it doesn't happen for a while. I'm not sure
>>> that anyone
>>> who is capable of doing it is particularly motivated to do it (though
>>> I'm not
>>> sure that they're _not_ either). It was clear that a number of people
>>> wanted
>>> assert to be smarter rather than having assertPred, but it isn't clear
>>> that
>>> assert is going to be made smarter any time soon. I suspect that it
>>> will be a
>>> while before it's done. We'll have to wait and see though.
>>
>> IIUC:
>> The problem is this feature belongs to the category of things that
>> cannot be implemented by any D programmer, in D, as a lib feature, even
>> by an expert in the domain.
>> It needs to get a representation of the unevaluated expression beeing
>> asserted, meaning compiler support, meaning hard low-level C/++ and a
>> great knowledge of the compiler architecture, esp the construction of
>> the AST. If there was a way to "quote" D expressions, and get their
>> representation at runtime, then we could do it ourselves (would imply
>> some perf penalty, but I consider this worth compared to the terrible
>> expressive power gained, and in fact totally neglectible for an assert
>> statement).
>> Please tell me where I'm wrong.
>>
>> With the same power, I would implement at once 'varWrite':
>> int x = 3; s = square(x);
>> varWrite("value: 'x' --> square: 's'");
>> // --> "value: 3 --> square: 9"
>> or even maybe:
>> int x = 3;
>> varWrite("value: 'x' --> square: 'x*x'");
>> // --> "value: 3 --> square: 9"
>>
>>
>> Denis
>
> String mixins ?

Works not, strings must be known at compile-time. And I don't want black magic.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com