[Issue 1961] Allow "scoped const" contracts (page 2)

http://d.puremagic.com/issues/show_bug.cgi?id=1961 ------- Comment #12 from maxmo@pochta.ru 2008-12-02 04:19 ------- > Walter Bright wrote: > > For me, the question is is solving these issues a large enough problem that justifies adding a rather confusing new variation on const? > This code duplication bug requires to write every rom method in three flavors to provide good rom interface. For me, this entirely prevents use of const system in OOP, restricting it to POD alone. I consider this a large enough problem, worth of new flavor of const. And this feature is not that confusing, if anyone wants a really confusing feature, he can look at the D templates :) --

http://d.puremagic.com/issues/show_bug.cgi?id=1961 fawzi@gmx.ch changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |noshiika@gmail.com ------- Comment #13 from fawzi@gmx.ch 2008-12-02 06:54 ------- Another kind of solution to this problem, more complex to create, but maybe cleaner is to have templates to extract/change the constness of types. I am not familiar with D2, so maybe what I say is already doable, or fully wrong. In particular this assumes that a type variable T contains also the constness attributes. This is not the case now (I think) otherwise things like the min example would be already correct, but I am not fully sure because the this template arguments seem to pick constness up. I am not sure I fully grasp the implications of adding constness attributes to type variables, I think that one problem could be that the matching becomes more difficult: with: T min(T)(T a,T b) then min(const(int),invariant(int)) should instantiate with T=const(int) min(invariant(int),invariant(int)) should instantiate with T=invariant(int) min(const(int),int) should instantiate min(int,int) ??? min(invariant(int),int) should not instantiate but I see not insormountable problems Then one wants functions like naked!(T) // removed eventual const/invariant from T (naked could maybe also be T.base, as .base is already used in a similar context) constness!(T) // returns an object (int?) representing the constness of T set_constness!(T,const_val) // returns the type const(naked(T)), invariant(naked(T)), naked(T) depending on const_val also strstr can be solved set_constness!(char,constness!(U)) strstr(U:char[])(U source, char[] pattern){ // .... } Using these functions (and assuming constness is ordered, which is trivial to do) one can then build something like min_constness!(...) // returning the minimal constness of its arguments max_constness!(...) // returning the maximal constness of its arguments If one also has aliases like "function" to return the argument type tuple (used in is expressions). I think that this in combination with template constraints, allows all the freedom one could possibly want. --

December 02, 2008

[Issue 1961] Allow "scoped const" contracts

Posted by d-bugmail
in reply to d-bugmail

Permalink

d-bugmail

Posted in reply to d-bugmail

Permalink

http://d.puremagic.com/issues/show_bug.cgi?id=1961





------- Comment #15 from schveiguy@yahoo.com  2008-12-02 09:07 -------
(In reply to comment #12)
> This code duplication bug requires to write every rom method in three flavors to provide good rom interface. For me, this entirely prevents use of const system in OOP, restricting it to POD alone. I consider this a large enough problem, worth of new flavor of const. And this feature is not that confusing, if anyone wants a really confusing feature, he can look at the D templates :)

Thanks for the support, please vote for the issue so it goes up the list!

 (In reply to comment #13)
> Another kind of solution to this problem, more complex to create, but maybe cleaner is to have templates to extract/change the constness of types.

This works today, in fact it is the same solution I bring up in the beginning of the bug report (with slight variations).  But there are several drawbacks:

1. Different arguments create different identical template instantiations.
Const does not affect actual assembly generated, it is simply a safeguard for
the compiler to enforce.  Start creating functions with 2 or 3 const args, and
you are exponentially increasing the number of possible template
instantiations.
2. As a user of the function, I must read the function to tell if any
specialization is done depending on the constness of the type.  For example, a
static if can easily detect the absence of const and modify the data.  In
addition, there is no indication that the function works with const types
anyways, just seeing a T does not tell me immediately that the function will
not modify the args, I must either try to use the function or read the
function.
3. Template functions cannot be virtual.
4. What do you do when the return value depends on the constness of multiple
arguments?  I guess you have a plausible solution, but you still have to mark
the function somehow.  Using templates, you would need a very convoluted
template structure to do this, and you may even need to ensure a certain type
of argument.

I think my proposal has none of these drawbacks, and all the same benefits as your proposal.  The only valid drawback anyone has brought up is the additional const specifier possibly making const even more confusing.  Although I still contend that this method would be much easier to understand and explain than any template or set of 3^n different versions of a function.  Perhaps the choice of keyword needs to be examined.


--

http://d.puremagic.com/issues/show_bug.cgi?id=1961 ------- Comment #16 from fawzi@gmx.ch 2008-12-02 09:57 ------- You are right I hadn't fully re-read the your initial posting, it was a long time ago ;) --

http://d.puremagic.com/issues/show_bug.cgi?id=1961 smjg@iname.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |smjg@iname.com ------- Comment #17 from smjg@iname.com 2008-12-07 11:57 ------- I like this idea. It would achieve the const-transparency that would be useful for COW string functions and the like. http://tinyurl.com/5dp6fn --

http://d.puremagic.com/issues/show_bug.cgi?id=1961 Steven Schveighoffer <schveiguy@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |3748 --- Comment #18 from Steven Schveighoffer <schveiguy@yahoo.com> 2010-02-18 06:55:00 PST --- It has been agreed that this will be implemented (pretty much as described). However, the first attempt by Walter did not work correctly. I filed bug 3748 that specifically identifies the implementation issues. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1961 Steven Schveighoffer <schveiguy@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #19 from Steven Schveighoffer <schveiguy@yahoo.com> 2010-05-18 03:47:59 PDT --- Closing this, the feature implementation will be tracked via bug 3748 as a bug instead of an enhancement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

Forums