Begin specifying object model #393
Conversation
This change begins to define the object model for HLSL and clearly denotes aggregate and non-aggregate types. It provides base definitions for sub-object ordering and scalar elementwise ordering. It also defines non-decomposable objects and stubs out sections for constructon and access control. HLSL does not currently support user-defined constructors or access control specifiers, however both are used implicitly and denote non-decomposible objects. Fixes microsoft#372
| assignment-expression in an initializer-list and performing a depth-first | ||
| traversal accessing each subobject of the assignment-expression. | ||
| which may be a scalar or aggregate type. A \textit{element-wise initializer | ||
| sequence} is constructed by concatenating the scalar element ordering |
There was a problem hiding this comment.
I think I see how this would work for matricies and vectors and 1 dim arrays. I'm not as clear on how it works for multi dim Arrays and Classes of classes/structs. I think the depth-first traversal algorithm covered finding these nested initalizers. Can you explain what concatenating is doing here to cover cases like arrays of classes and classes of classes?
Second should we link scalar element ordering to line 363 in specs/language/introduction.tex?
When I think scalar i'm thinking the non container types like primitive types like float/int/bool/etc which makes me think we are excluding classes, but thats at odds with the types Aggregate Initialization covers.
There was a problem hiding this comment.
Are you suggesting something other than the (\ref{Intro.Object.SubOrdering}) that is right after the use of the term?
| \(E_n\)'s type. | ||
| target object's scalar element ordering there is a corresponding initializer | ||
| \(I_n\) in the element-wise initializer sequence which can be implicitly | ||
| converted to the element's type. |
There was a problem hiding this comment.
Maybe reference E_n here, 'which can be implicitly converted to 'E_n's type'
| called a \textit{sub-object}. An object that is not contained by any other object | ||
| is called a \textit{complete object}. | ||
|
|
||
| \p An object or sub-object that is a non-intangible type will have an associated |
There was a problem hiding this comment.
I think I recall there being some disagreement about this term before, non-intangible type. I think its easy to skim over this word and hear 'non tangible' type. Could we be more clear and say 'Not an Intangible type'? Or do we need a one word phrase?
|
|
||
| \p An object or sub-object that is a non-intangible type will have an associated | ||
| memory location. An object of intangible type will only have a memory location | ||
| if it contains a sub-object of non-intangible type (\ref{Basic.types}). |
This change begins to define the object model for HLSL and clearly denotes aggregate and non-aggregate types. It provides base definitions for sub-object ordering and scalar elementwise ordering. It also defines non-decomposable objects and stubs out sections for constructon and access control.
HLSL does not currently support user-defined constructors or access control specifiers, however both are used implicitly and denote non-decomposible objects.
Fixes #372