> On May 20, 2016, at 7:56 AM, Chris Lattner <clatt...@apple.com> wrote:
> On May 12, 2016, at 4:03 PM, John McCall via swift-dev <swift-dev@swift.org>
> wrote:
>
>>>> On May 12, 2016, at 3:21 PM, Joe Groff <jgr...@apple.com> wrote:
>>>>> On May 12, 2016, at 11:21 AM, John McCall <rjmcc...@apple.com> wrote:
>>>>>
>>>>>> On May 12, 2016, at 10:45 AM, Jordan Rose via swift-dev
>>>>>> <swift-dev@swift.org> wrote:
>>>>>> On May 12, 2016, at 10:44, Joe Groff <jgr...@apple.com> wrote:
>>>>>>
>>>>>>
>>>>>>> On May 12, 2016, at 9:27 AM, Jordan Rose via swift-dev
>>>>>>> <swift-dev@swift.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>> - I’m uncomfortable with using the term “undefined behavior” as if it’s
>>>>>>> universally understood. Up until now we haven't formally had that
>>>>>>> notion in Swift, just “type safety” and “memory safety” and
>>>>>>> “invariant-preserving” and the like. Maybe we need it now, but I think
>>>>>>> it needs to be explicitly defined. (I’d actually talk to Dave about
>>>>>>> exactly what terms make the most sense for users.)
>>>>>>
>>>>>> We do have undefined behavior, and use that term in the standard library
>>>>>> docs where appropriate:
>>>>>>
>>>>>> stdlib/public/core/Optional.swift- /// `!` (forced unwrap) operator.
>>>>>> However, in optimized builds (`-O`), no
>>>>>> stdlib/public/core/Optional.swift- /// check is performed to ensure
>>>>>> that the current instance actually has a
>>>>>> stdlib/public/core/Optional.swift- /// value. Accessing this property
>>>>>> in the case of a `nil` value is a serious
>>>>>> stdlib/public/core/Optional.swift: /// programming error and could lead
>>>>>> to undefined behavior or a runtime
>>>>>> stdlib/public/core/Optional.swift- /// error.
>>>>>> stdlib/public/core/Optional.swift- ///
>>>>>> stdlib/public/core/Optional.swift- /// In debug builds (`-Onone`), the
>>>>>> `unsafelyUnwrapped` property has the same
>>>>>> --
>>>>>> stdlib/public/core/StringBridge.swift- /// The caller of this function
>>>>>> guarantees that the closure 'body' does not
>>>>>> stdlib/public/core/StringBridge.swift- /// escape the object referenced
>>>>>> by the opaque pointer passed to it or
>>>>>> stdlib/public/core/StringBridge.swift- /// anything transitively
>>>>>> reachable form this object. Doing so
>>>>>> stdlib/public/core/StringBridge.swift: /// will result in undefined
>>>>>> behavior.
>>>>>> stdlib/public/core/StringBridge.swift-
>>>>>> @_semantics("self_no_escaping_closure")
>>>>>> stdlib/public/core/StringBridge.swift- func
>>>>>> _unsafeWithNotEscapedSelfPointer<Result>(
>>>>>> stdlib/public/core/StringBridge.swift- _ body: @noescape
>>>>>> (OpaquePointer) throws -> Result
>>>>>> --
>>>>>> stdlib/public/core/Unmanaged.swift- /// reference's lifetime fixed for
>>>>>> the duration of the
>>>>>> stdlib/public/core/Unmanaged.swift- /// '_withUnsafeGuaranteedRef' call.
>>>>>> stdlib/public/core/Unmanaged.swift- ///
>>>>>> stdlib/public/core/Unmanaged.swift: /// Violation of this will incur
>>>>>> undefined behavior.
>>>>>> stdlib/public/core/Unmanaged.swift- ///
>>>>>> stdlib/public/core/Unmanaged.swift- /// A lifetime of a reference 'the
>>>>>> instance' is fixed over a point in the
>>>>>> stdlib/public/core/Unmanaged.swift- /// programm if:
>>>>>
>>>>> Those latter two are in stdlib-internal declarations. I think I have the
>>>>> same objection with using the term for 'unsafelyUnwrapped'.
>>>>
>>>> Well, we can say "A program has undefined behavior if it does X or Y", or
>>>> we can say "A program which does X or Y lacks type safety". In all cases
>>>> we are referring to a concept defined elsewhere. If we say "undefined
>>>> behavior", we are using an easily-googled term whose popular discussions
>>>> will quickly inform the reader of the consequences of the violation. If
>>>> we say "type safety", we are using a term with that's popularly used in
>>>> very vague, hand-wavey ways and whose consequences aren't usually
>>>> discussed outside of formal contexts. If we say "memory safety", we're
>>>> using a term that doesn't even have that precedent. So we can use the
>>>> latter two terms if we want, but that just means we need to have a
>>>> standard place where we define them and describe the consequences of
>>>> violating them, probably with at least a footnote saying "this is
>>>> analogous to the undefined behavior rules of C and C++".
>>>
>>> In other places where the standard library intentionally has undefined
>>> behavior, it looks like we use the term "serious programming error", for
>>> instance in the the doc comment for `assert`:
>>>
>>> /// * In -Ounchecked builds, `condition` is not evaluated, but the
>>> /// optimizer may assume that it *would* evaluate to `true`. Failure
>>> /// to satisfy that assumption in -Ounchecked builds is a serious
>>> /// programming error.
>>>
>>> which feels a bit colloquial to me, and doesn't provide much insight into
>>> the full consequences of UB. I think we're better off using an established
>>> term.
>>
>> Agreed.
>>
>> Do we have a good place to document common terms? Preferably one that isn't
>> a book?
>
> We cite Wikipedia in the stdlib doc comments, why can't we cite TSPL, and put
> the detailed discussion there?
I don't feel comfortable editing TSPL. Should I?
John.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
